Re: [PATCH v13 12/32] x86,fs/resctrl: Support binary fixed point event counters

["Luck, Tony" <tony.luck@intel.com>]

On Tue, Nov 11, 2025 at 05:16:22PM +0000, Dave Martin wrote:

... snip

> > I'm not a fan of the "floor" option. Looks like it loses precision.  Terrible for
> 
> Loses precision, but does not advertise bogus precision precision
> beyond the precision in the original value.  (This is why it is not
> standard to print doubles with more then 15 significant digits, even
> though 17 significant digits are needed for bit-exact reproduction.)
> 
> I don't know whether this matters relative to the use cases, but it
> would be nice to have some rationale.
> 
> > 1-3 binary bits. Also not what I'd like for the bits==18 case that I currently
> > care about.
> > 
> > "ceil" is good for bits > 6. Almost matches my numbers (except I jump
> > to one more decimal place one binary bit earlier).
> > 
> > What do you think of me swapping out the values from 7 upwards for the
> > ceil values and documenting that 0..6 are hand-picked, but 7 and up are
> > ceil(binary_bits * log10_2)?
> 
> If there is sound rationale for hand-picking some values then yes.
> 
> I haven't yet been convinced that there is ;)

I don't have a rationale and I've been doing the thing I tell others
not to do "getting attached to code that I wrote". I will switch the
whole table to the ceil(binary_bits * log10_2) values.

One exception for binary_bits == 0. Back in the v6 version of these
patches I printed as a plain integer. Reinette commented[1]:

    At this time I understand that it will be clear for which
    events user space expects floating point numbers. If the architecture in
    turn does not support any "binary bits" then I think resctrl
    should still print a floating point number ("x.0") to match user space
    expectation.

-Tony

Link: https://lore.kernel.org/all/8214ae1f-d64c-496c-b41d-13b31250acea@intel.com/ [1]