[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: API/ABIs: Re: [RFC PATCH v2 0/2] Add a new acquire resource to query vcpu statistics
- To: Matias Ezequiel Vara Larsen <matiasevara@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 10 Mar 2023 12:34:33 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XtAO+LkBGlTmagpm9MRkLXF3fcQlt9QAIZV9F97neJg=; b=d/MRmSVUsRoA1YDAtwPXbt2pm0CW028M/2v8u7W+4QfhLuKA+o1EfThsRaTBfGWkdSWL7AWl0HspHSBxIR1vsLTRCF23Lj6uRel2lsdw0QJHvnqnWDxDB97lEnPugydTBw12MOXp8X+Nj+SknELHciXxYAndsTeoLwAU2fSIlAoh2b2LbfSR9oKKXGR842N6tcd/V8dJWr6gYmUtLeLLoVx0nSHxn6mRKI4VZGyBfwsX587Z4mnezlUCKtPMXgaIF6Vm9S6kTEqI+9s0z0bvS1evahTezmv67k2kX0vSQ3QomU/Gn6bXuaKdRmEP6YrLn6k1vZvo9iNrhSZ70KA0+g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ImtHUD2feFop610bluTLGn2wMD6tmTohwlWOfgnhWNW3jR/SDhlm1l9LIDm7l+UqDe4MQMGzZK6ofrQNVylWb17M6kgn+nU+oPUYe4h0kPj9/Y6T7HJ1ywUUX/57zr3UkY51fY96wuIpMXeXoALxsRubEz5AHOdI3hXyFUF3vJ+DapJBZ7kvnVwlgm48rU4fgu1HItq2D8xNf1G2X1bsdSukjWfg4EsRpHgDKfXbydywFjaKTbXXTShLCi70j5+mYo1Lbr7yfWPy/EwSfhTu2MCbfKAANWm0HNq5WrX8Kmwaoa3GVMG2Llt9DvqwjqfBvwfkOvXMQygfiZbpYpycUw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Matias Ezequiel Vara Larsen <matias.vara@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Fri, 10 Mar 2023 11:34:59 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10.03.2023 11:58, Matias Ezequiel Vara Larsen wrote:
> Oh, I see, thanks for the clarification. To summarise, these are the current
> options:
> 1. Use a "uint64_t" field thus limiting the number of counters to 64. The
> current vcpu_runstate_info structure is limited to 4 counters though, one for
> each RUNSTATE_*.
> 2. Use a dynamic array but this makes harder to use the interface.
> 3. Eliminate stats_active and set to ~0 the actual stats value to mark
> inactive
> counters. This requires adding a "nr_stats" field to know how many counters
> are.
While nr_stats can indeed be seen as a generalization of the earlier
stats_active, I think it is possible to get away without, as long as
padding fields also are filled with the "inactive" marker.
> Also, this requires to make sure to saturate at 2^^64-2.
Thinking of it - considering overflowed counters inactive looks like a
reasonable model to me as well (which would mean saturating at 2^^64-1).
> I might miss some details here but these are the options to evaluate.
>
> I would go with a variation of 1) by using two uint64_t, i.e., up to 128
> vcpu's
> counters, which I think it would be enough. I may be wrong.
Well, to me it doesn't matter whether it's 32, 64, or 128 - my concern
is with any kind of inherent upper bound. Using 128 right away might
look excessive, just like 32 might look too little. Hence my desire to
get away without any built-in upper bound. IOW I continue to favor 3,
irrespective of the presence or absence of nr_stats.
Jan
|
