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
