Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Andy Shevchenko]

On Mon, Dec 21, 2015 at 6:16 PM, Matt Fleming  wrote:
> On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
>> Print the base address for each range in decimal alongside the size.
>> Use a "(size @ base)" format similar to the fake_memmap kernel parameter.
>>
>> Print the range and base in the best-fit B, KiB, MiB, etc. units rather
>> than always MiB.  This avoids rounding, which can be misleading.
>>
>> Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
>> decimal units (KB, MB, etc.).
>>
>> old:
>> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
>> range=[0x00088000-0x000c7fff) (16384MB)
>>
>> new:
>> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
>> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
>>
>> Signed-off-by: Robert Elliott 
>> ---
>>  arch/x86/platform/efi/efi.c | 27 ---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>
> I'm not at all sure of the value of printing the physical address as a
> size. I would have thought that you'd have to convert it back to an
> address whenever you wanted to use it anyway.
>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 635a955..030ba91 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
>>   return 0;
>>  }
>>
>> +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
>> +{
>> + if (!bytes || (bytes & 0x3ff))
>> + snprintf(buf, size, "%llu B", bytes);
>> + else if (bytes & 0xf)
>> + snprintf(buf, size, "%llu KiB", bytes >> 10);
>> + else if (bytes & 0x3fff)
>> + snprintf(buf, size, "%llu MiB", bytes >> 20);
>> + else if (bytes & 0xff)
>> + snprintf(buf, size, "%llu GiB", bytes >> 30);
>> + else if (bytes & 0x3)
>> + snprintf(buf, size, "%llu TiB", bytes >> 40);
>> + else if (bytes & 0xfff)
>> + snprintf(buf, size, "%llu PiB", bytes >> 50);
>> + else
>> + snprintf(buf, size, "%llu EiB", bytes >> 60);
>> + return buf;

For me it looks like ffs with name in the table can be used.

>> +}
>> +
>
> Can we use string_get_size() instead of rolling our own function?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Andy Shevchenko]

On Mon, Dec 21, 2015 at 6:16 PM, Matt Fleming  wrote:
> On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
>> Print the base address for each range in decimal alongside the size.
>> Use a "(size @ base)" format similar to the fake_memmap kernel parameter.
>>
>> Print the range and base in the best-fit B, KiB, MiB, etc. units rather
>> than always MiB.  This avoids rounding, which can be misleading.
>>
>> Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
>> decimal units (KB, MB, etc.).
>>
>> old:
>> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
>> range=[0x00088000-0x000c7fff) (16384MB)
>>
>> new:
>> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
>> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
>>
>> Signed-off-by: Robert Elliott 
>> ---
>>  arch/x86/platform/efi/efi.c | 27 ---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>
> I'm not at all sure of the value of printing the physical address as a
> size. I would have thought that you'd have to convert it back to an
> address whenever you wanted to use it anyway.
>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 635a955..030ba91 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
>>   return 0;
>>  }
>>
>> +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
>> +{
>> + if (!bytes || (bytes & 0x3ff))
>> + snprintf(buf, size, "%llu B", bytes);
>> + else if (bytes & 0xf)
>> + snprintf(buf, size, "%llu KiB", bytes >> 10);
>> + else if (bytes & 0x3fff)
>> + snprintf(buf, size, "%llu MiB", bytes >> 20);
>> + else if (bytes & 0xff)
>> + snprintf(buf, size, "%llu GiB", bytes >> 30);
>> + else if (bytes & 0x3)
>> + snprintf(buf, size, "%llu TiB", bytes >> 40);
>> + else if (bytes & 0xfff)
>> + snprintf(buf, size, "%llu PiB", bytes >> 50);
>> + else
>> + snprintf(buf, size, "%llu EiB", bytes >> 60);
>> + return buf;

For me it looks like ffs with name in the table can be used.

>> +}
>> +
>
> Can we use string_get_size() instead of rolling our own function?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Matt Fleming]

On Wed, 23 Dec, at 12:11:56AM, Elliott, Robert (Persistent Memory) wrote:
> 
> I was trying to make it resemble the memmap=size@address 
> kernel parameter format for creating e820 entries, which
> does accept abbreviations in addition to hex values:
>   memmap=nn[KMG]@ss[KMG] for usable DRAM
>   memmap=nn[KMG]#ss[KMG] for ACPI data
>   memmap=nn[KMG]$ss[KMG] for reserved
>   memmap=nn[KMG]!ss[KMG] for persistent memory
> 
> Mapping the UEFI type to the corresponding @, #, $, or ! was
> more than I wanted to tackle, so it's not a drop-in
> replacement string.
> 
> memparse() also accepts T, P, and E units; I guess those
> need to be added to Documentation/kernel-parameters.txt.
 
I think the value of the "@ address" portion of the string is
questionable.

> Thanks for the pointer; I wondered if there was a similar
> function somewhere.  However, that function throws away
> precision in favor of printing just 3 significant digits;
> I think that's dangerous.  Its non-integer output is not
> supported by memmap=, and the function appears to use
> assembly code to get CPU divide instructions, losing the
> ability to use shifts for these power of two divisions.
> 
> Example results...
> 
> efi: mem01:... range=[0x00093000-0x00093fff] (4 KiB @ 588 KiB)
> efi: mem01:... range=[0x00093000-0x00093fff] (4.00 KiB @ 588 
> KiB) SGS
> 
> efi: mem03:... range=[0x0010-0x013e8fff] (19364 KiB @ 1 
> MiB)
> efi: mem03:... range=[0x0010-0x013e8fff] (18.9 MiB @ 1.00 
> MiB) SGS
> (example of lost precision: 19364 KiB is really 18.91015625 MiB)
> 
> efi: mem04:... range=[0x013e9000-0x01ff] (12380 KiB @ 
> 20388 KiB)
> efi: mem04:... range=[0x013e9000-0x01ff] (12.0 MiB @ 19.9 
> MiB) SGS
> 
> efi: mem28:... range=[0x717c2000-0x72acafff] (19492 KiB @ 
> 1859336 KiB)
> efi: mem28:... range=[0x717c2000-0x72acafff] (19.0 MiB @ 1.77 
> GiB) SGS
> 
> efi: mem57:... range=[0x00088000-0x000e7fff] (24 GiB @ 34 GiB)
> efi: mem57:... range=[0x00088000-0x000e7fff] (24.0 GiB @ 34.0 
> GiB) SGS

Good points! I agree that string_get_size() (unfortunately) doesn't
look useful in this scenario. The code in efi_size_format() looks
fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Matt Fleming]

On Wed, 23 Dec, at 12:11:56AM, Elliott, Robert (Persistent Memory) wrote:
> 
> I was trying to make it resemble the memmap=size@address 
> kernel parameter format for creating e820 entries, which
> does accept abbreviations in addition to hex values:
>   memmap=nn[KMG]@ss[KMG] for usable DRAM
>   memmap=nn[KMG]#ss[KMG] for ACPI data
>   memmap=nn[KMG]$ss[KMG] for reserved
>   memmap=nn[KMG]!ss[KMG] for persistent memory
> 
> Mapping the UEFI type to the corresponding @, #, $, or ! was
> more than I wanted to tackle, so it's not a drop-in
> replacement string.
> 
> memparse() also accepts T, P, and E units; I guess those
> need to be added to Documentation/kernel-parameters.txt.
 
I think the value of the "@ address" portion of the string is
questionable.

> Thanks for the pointer; I wondered if there was a similar
> function somewhere.  However, that function throws away
> precision in favor of printing just 3 significant digits;
> I think that's dangerous.  Its non-integer output is not
> supported by memmap=, and the function appears to use
> assembly code to get CPU divide instructions, losing the
> ability to use shifts for these power of two divisions.
> 
> Example results...
> 
> efi: mem01:... range=[0x00093000-0x00093fff] (4 KiB @ 588 KiB)
> efi: mem01:... range=[0x00093000-0x00093fff] (4.00 KiB @ 588 
> KiB) SGS
> 
> efi: mem03:... range=[0x0010-0x013e8fff] (19364 KiB @ 1 
> MiB)
> efi: mem03:... range=[0x0010-0x013e8fff] (18.9 MiB @ 1.00 
> MiB) SGS
> (example of lost precision: 19364 KiB is really 18.91015625 MiB)
> 
> efi: mem04:... range=[0x013e9000-0x01ff] (12380 KiB @ 
> 20388 KiB)
> efi: mem04:... range=[0x013e9000-0x01ff] (12.0 MiB @ 19.9 
> MiB) SGS
> 
> efi: mem28:... range=[0x717c2000-0x72acafff] (19492 KiB @ 
> 1859336 KiB)
> efi: mem28:... range=[0x717c2000-0x72acafff] (19.0 MiB @ 1.77 
> GiB) SGS
> 
> efi: mem57:... range=[0x00088000-0x000e7fff] (24 GiB @ 34 GiB)
> efi: mem57:... range=[0x00088000-0x000e7fff] (24.0 GiB @ 34.0 
> GiB) SGS

Good points! I agree that string_get_size() (unfortunately) doesn't
look useful in this scenario. The code in efi_size_format() looks
fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: Matt Fleming [mailto:m...@codeblueprint.co.uk]
> Sent: Monday, December 21, 2015 10:16 AM
> To: Elliott, Robert (Persistent Memory) 
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 4/4] x86/efi: print size and base in binary units in
> efi_print_memmap
> 
> On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
> > Print the base address for each range in decimal alongside the size.
> > Use a "(size @ base)" format similar to the fake_memmap kernel
> parameter.
> >
> > Print the range and base in the best-fit B, KiB, MiB, etc. units rather
> > than always MiB.  This avoids rounding, which can be misleading.
> >
> > Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
> > decimal units (KB, MB, etc.).
> >
> > old:
> > efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff) (16384MB)
> >
> > new:
> > efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
> >
> > Signed-off-by: Robert Elliott 
> > ---
> >  arch/x86/platform/efi/efi.c | 27 ---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> I'm not at all sure of the value of printing the physical address as a
> size. I would have thought that you'd have to convert it back to an
> address whenever you wanted to use it anyway.

I was trying to make it resemble the memmap=size@address 
kernel parameter format for creating e820 entries, which
does accept abbreviations in addition to hex values:
memmap=nn[KMG]@ss[KMG] for usable DRAM
memmap=nn[KMG]#ss[KMG] for ACPI data
memmap=nn[KMG]$ss[KMG] for reserved
memmap=nn[KMG]!ss[KMG] for persistent memory

Mapping the UEFI type to the corresponding @, #, $, or ! was
more than I wanted to tackle, so it's not a drop-in
replacement string.

memparse() also accepts T, P, and E units; I guess those
need to be added to Documentation/kernel-parameters.txt.

> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 635a955..030ba91 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
> > return 0;
> >  }
> >
> > +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
> > +{
> > +   if (!bytes || (bytes & 0x3ff))
> > +   snprintf(buf, size, "%llu B", bytes);
> > +   else if (bytes & 0xf)
> > +   snprintf(buf, size, "%llu KiB", bytes >> 10);
> > +   else if (bytes & 0x3fff)
> > +   snprintf(buf, size, "%llu MiB", bytes >> 20);
> > +   else if (bytes & 0xff)
> > +   snprintf(buf, size, "%llu GiB", bytes >> 30);
> > +   else if (bytes & 0x3)
> > +   snprintf(buf, size, "%llu TiB", bytes >> 40);
> > +   else if (bytes & 0xfff)
> > +   snprintf(buf, size, "%llu PiB", bytes >> 50);
> > +   else
> > +   snprintf(buf, size, "%llu EiB", bytes >> 60);
> > +   return buf;
> > +}
> > +
> 
> Can we use string_get_size() instead of rolling our own function?

Thanks for the pointer; I wondered if there was a similar
function somewhere.  However, that function throws away
precision in favor of printing just 3 significant digits;
I think that's dangerous.  Its non-integer output is not
supported by memmap=, and the function appears to use
assembly code to get CPU divide instructions, losing the
ability to use shifts for these power of two divisions.

Example results...

efi: mem01:... range=[0x00093000-0x00093fff] (4 KiB @ 588 KiB)
efi: mem01:... range=[0x00093000-0x00093fff] (4.00 KiB @ 588 
KiB) SGS

efi: mem03:... range=[0x0010-0x013e8fff] (19364 KiB @ 1 MiB)
efi: mem03:... range=[0x0010-0x013e8fff] (18.9 MiB @ 1.00 
MiB) SGS
(example of lost precision: 19364 KiB is really 18.91015625 MiB)

efi: mem04:... range=[0x013e9000-0x01ff] (12380 KiB @ 20388 
KiB)
efi: mem04:... range=[0x013e9000-0x01ff] (12.0 MiB @ 19.9 
MiB) SGS

efi: mem28:... range=[0x717c2000-0x72acafff] (19492 KiB @ 
1859336 KiB)
efi: mem28:... range=[0x717c2000-0x72acafff] (19.0 MiB @ 1.77 
GiB) SGS

efi: mem57:... range=[0x00088000-0x000e7fff] (24 GiB @ 34 GiB)
efi: mem57:... range=[0x00088000-0x000e7fff] (24.0 GiB @ 34.0 
GiB) SGS

---
Robert Elliott, HPE Persistent Memory

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: Matt Fleming [mailto:m...@codeblueprint.co.uk]
> Sent: Monday, December 21, 2015 10:16 AM
> To: Elliott, Robert (Persistent Memory) 
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 4/4] x86/efi: print size and base in binary units in
> efi_print_memmap
> 
> On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
> > Print the base address for each range in decimal alongside the size.
> > Use a "(size @ base)" format similar to the fake_memmap kernel
> parameter.
> >
> > Print the range and base in the best-fit B, KiB, MiB, etc. units rather
> > than always MiB.  This avoids rounding, which can be misleading.
> >
> > Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
> > decimal units (KB, MB, etc.).
> >
> > old:
> > efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff) (16384MB)
> >
> > new:
> > efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
> >
> > Signed-off-by: Robert Elliott 
> > ---
> >  arch/x86/platform/efi/efi.c | 27 ---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> I'm not at all sure of the value of printing the physical address as a
> size. I would have thought that you'd have to convert it back to an
> address whenever you wanted to use it anyway.

I was trying to make it resemble the memmap=size@address 
kernel parameter format for creating e820 entries, which
does accept abbreviations in addition to hex values:
memmap=nn[KMG]@ss[KMG] for usable DRAM
memmap=nn[KMG]#ss[KMG] for ACPI data
memmap=nn[KMG]$ss[KMG] for reserved
memmap=nn[KMG]!ss[KMG] for persistent memory

Mapping the UEFI type to the corresponding @, #, $, or ! was
more than I wanted to tackle, so it's not a drop-in
replacement string.

memparse() also accepts T, P, and E units; I guess those
need to be added to Documentation/kernel-parameters.txt.

> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 635a955..030ba91 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
> > return 0;
> >  }
> >
> > +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
> > +{
> > +   if (!bytes || (bytes & 0x3ff))
> > +   snprintf(buf, size, "%llu B", bytes);
> > +   else if (bytes & 0xf)
> > +   snprintf(buf, size, "%llu KiB", bytes >> 10);
> > +   else if (bytes & 0x3fff)
> > +   snprintf(buf, size, "%llu MiB", bytes >> 20);
> > +   else if (bytes & 0xff)
> > +   snprintf(buf, size, "%llu GiB", bytes >> 30);
> > +   else if (bytes & 0x3)
> > +   snprintf(buf, size, "%llu TiB", bytes >> 40);
> > +   else if (bytes & 0xfff)
> > +   snprintf(buf, size, "%llu PiB", bytes >> 50);
> > +   else
> > +   snprintf(buf, size, "%llu EiB", bytes >> 60);
> > +   return buf;
> > +}
> > +
> 
> Can we use string_get_size() instead of rolling our own function?

Thanks for the pointer; I wondered if there was a similar
function somewhere.  However, that function throws away
precision in favor of printing just 3 significant digits;
I think that's dangerous.  Its non-integer output is not
supported by memmap=, and the function appears to use
assembly code to get CPU divide instructions, losing the
ability to use shifts for these power of two divisions.

Example results...

efi: mem01:... range=[0x00093000-0x00093fff] (4 KiB @ 588 KiB)
efi: mem01:... range=[0x00093000-0x00093fff] (4.00 KiB @ 588 
KiB) SGS

efi: mem03:... range=[0x0010-0x013e8fff] (19364 KiB @ 1 MiB)
efi: mem03:... range=[0x0010-0x013e8fff] (18.9 MiB @ 1.00 
MiB) SGS
(example of lost precision: 19364 KiB is really 18.91015625 MiB)

efi: mem04:... range=[0x013e9000-0x01ff] (12380 KiB @ 20388 
KiB)
efi: mem04:... range=[0x013e9000-0x01ff] (12.0 MiB @ 19.9 
MiB) SGS

efi: mem28:... range=[0x717c2000-0x72acafff] (19492 KiB @ 
1859336 KiB)
efi: mem28:... range=[0x717c2000-0x72acafff] (19.0 MiB @ 1.77 
GiB) SGS

efi: mem57:... range=[0x00088000-0x000e7fff] (24 GiB @ 34 GiB)
efi: mem57:... range=[0x00088000-0x000e7fff] (24.0 GiB @ 34.0 
GiB) SGS

---
Robert Elliott, HPE Persistent Memory

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Matt Fleming]

On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
> Print the base address for each range in decimal alongside the size.
> Use a "(size @ base)" format similar to the fake_memmap kernel parameter.
> 
> Print the range and base in the best-fit B, KiB, MiB, etc. units rather
> than always MiB.  This avoids rounding, which can be misleading.
> 
> Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
> decimal units (KB, MB, etc.).
> 
> old:
> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00088000-0x000c7fff) (16384MB)
> 
> new:
> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
> 
> Signed-off-by: Robert Elliott 
> ---
>  arch/x86/platform/efi/efi.c | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
 
I'm not at all sure of the value of printing the physical address as a
size. I would have thought that you'd have to convert it back to an
address whenever you wanted to use it anyway.

> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 635a955..030ba91 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
>   return 0;
>  }
>  
> +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
> +{
> + if (!bytes || (bytes & 0x3ff))
> + snprintf(buf, size, "%llu B", bytes);
> + else if (bytes & 0xf)
> + snprintf(buf, size, "%llu KiB", bytes >> 10);
> + else if (bytes & 0x3fff)
> + snprintf(buf, size, "%llu MiB", bytes >> 20);
> + else if (bytes & 0xff)
> + snprintf(buf, size, "%llu GiB", bytes >> 30);
> + else if (bytes & 0x3)
> + snprintf(buf, size, "%llu TiB", bytes >> 40);
> + else if (bytes & 0xfff)
> + snprintf(buf, size, "%llu PiB", bytes >> 50);
> + else
> + snprintf(buf, size, "%llu EiB", bytes >> 60);
> + return buf;
> +}
> +

Can we use string_get_size() instead of rolling our own function?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/efi: print size and base in binary units in efi_print_memmap

[Matt Fleming]

On Thu, 17 Dec, at 07:28:34PM, Robert Elliott wrote:
> Print the base address for each range in decimal alongside the size.
> Use a "(size @ base)" format similar to the fake_memmap kernel parameter.
> 
> Print the range and base in the best-fit B, KiB, MiB, etc. units rather
> than always MiB.  This avoids rounding, which can be misleading.
> 
> Use proper IEC binary units (KiB, MiB, etc.) rather than misuse SI
> decimal units (KB, MB, etc.).
> 
> old:
> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00088000-0x000c7fff) (16384MB)
> 
> new:
> efi: mem61: [Persistent Memory  |   |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00088000-0x000c7fff] (16 GiB @ 34 GiB)
> 
> Signed-off-by: Robert Elliott 
> ---
>  arch/x86/platform/efi/efi.c | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
 
I'm not at all sure of the value of printing the physical address as a
size. I would have thought that you'd have to convert it back to an
address whenever you wanted to use it anyway.

> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 635a955..030ba91 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -222,6 +222,25 @@ int __init efi_memblock_x86_reserve_range(void)
>   return 0;
>  }
>  
> +char * __init efi_size_format(char *buf, size_t size, u64 bytes)
> +{
> + if (!bytes || (bytes & 0x3ff))
> + snprintf(buf, size, "%llu B", bytes);
> + else if (bytes & 0xf)
> + snprintf(buf, size, "%llu KiB", bytes >> 10);
> + else if (bytes & 0x3fff)
> + snprintf(buf, size, "%llu MiB", bytes >> 20);
> + else if (bytes & 0xff)
> + snprintf(buf, size, "%llu GiB", bytes >> 30);
> + else if (bytes & 0x3)
> + snprintf(buf, size, "%llu TiB", bytes >> 40);
> + else if (bytes & 0xfff)
> + snprintf(buf, size, "%llu PiB", bytes >> 50);
> + else
> + snprintf(buf, size, "%llu EiB", bytes >> 60);
> + return buf;
> +}
> +

Can we use string_get_size() instead of rolling our own function?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/