Re: [dmidecode] [PATCH 1/2] dmidecode: Use the most appropriate unit for cache size

[Jean Delvare]

Hi Robert,

On Mon, 17 Dec 2018 15:50:18 +0000, Elliott, Robert (Persistent Memory) wrote:
> > -----Original Message-----
> > From: dmidecode-devel <address@hidden>
> > On Behalf Of Jean Delvare
> > Sent: Tuesday, December 11, 2018 2:20 PM
> > To: address@hidden
> > Subject: [dmidecode] [PATCH 1/2] dmidecode: Use the most appropriate unit
> > for cache size
> > 
> > As newer CPUs have larger and larger cache, using kB to represent the
> > cache size is getting less convenient. Reuse the same function we have
> > for system memory size so that large units will be used as
> > appropriate. For example, a cache size reported as "20 MB" looks nicer
> > than as "20480 kB".
> > -           if (code >= 0x8000)
> > -                   printf(" %u MB", code >> 4);
> > -           else
> > -                   printf(" %u kB", code << 6);
> > +           size.l = code << 6;
> > +           size.h = code >> 26;
> >     }
> >     else
> > -           printf(" %u kB", code);  
> 
> The value might not be an integer multiple of the larger prefix; if so,
> then you should either use floating point to show the fractional number
> (my recommendation), or stick with the smaller prefix.

The code above is not trimming any bit. The value passed to
dmi_print_memory_size() is an integer computed from the data encoded in
the DMI table.

The logic in dmi_print_memory_size() could indeed trim bits in theory:

        /*
         * Now we find the highest unit with a non-zero value. If the following
         * is also non-zero, we use that as our base. If the following is zero,
         * we simply display the highest unit.
         */

In practice however, it is not supposed to happen:

         * In practice, it is expected that only one or two
         * (consecutive) of these will be non-zero.

I have a huge collection of DMI table dumps and I have only ever seen
one case where this expectation wasn't met:

Handle 0x0028, DMI type 19, 31 bytes
Memory Array Mapped Address
        Starting Address: 0x0000000020000000k
        Ending Address: 0x000000007EFBFFFFk
        Range Size: 1519 MB
        Physical Array Handle: 0x0026
        Partition Width: 1

0x7EFBFFFF - 0x20000000 + 1 is 0x5EFC0000 which actually spans over 3
units: 1 GB + 495 MB + 768 kB.

(As a side note, the "k" at the end of the Starting Address and Ending
Address fields look wrong to me. I can't explain why they are here, the
specification clearly states that the extended values are in bytes, and
even for the non-extended values, which were in kB, the code is
converting them to bytes before printing them. Hmmpf, fishy.)

You are asking the question of how such a value should be displayed.

I'm not sure how a fractional number would improve the readability.
Would you really prefer "1519.75 MB" instead of "1519 MB"? I can't see
how it helps, especially when you can't guarantee a fully accurate
representation of the value anyway. Or would you go for "1.48 GB"?
That's possibly easier to read, but less accurate.

As to using the smallest unit which keeps the value fully accurate,
that would be kB in this case, so we would display "1556224 kB". This
is too many digits for my eyes to split in groups of 3 and have an
immediate estimation of how large the entity is.

All in all I still believe that the approach I took 8 years ago is the
best compromise between readability and accuracy. But if a majority of
users have a different opinion, I am ready to discuss a change.

But first of all: which problem are you trying to solve?

> Consider using this opportunity to switch to the SI-recommended IEC-defined
> prefixes for binary multiples: KiB (1024) and MiB (1024*1024) rather than
> KB (1000) and MB (1000*1000).

That would make some sense indeed, even though I think nobody sane uses
non-binary units for memory capacity, so I do not think the current
output is ambiguous. Only HDD and SSD vendors are doing it (and THAT is
confusing), presumably for marketing reasons ... using proper units
would make their drives look smaller than the competition.

That's a separate issue though, and such a change would have to be done
consistently in the whole dmidecode output and source code.

-- 
Jean Delvare
SUSE L3 Support