All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-kernel@vger.kernel.org, Andy Shevchenko <andy@kernel.org>,
	Arnd Bergmann <arnd@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Juergen Gross <jgross@suse.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Kees Cook <keescook@chromium.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PATCH 07/29] x86/boot/e820: Print out sizes of E820 memory ranges
Date: Thu, 15 May 2025 12:44:06 +0200	[thread overview]
Message-ID: <aCXFdvWiNW94F24R@gmail.com> (raw)
In-Reply-To: <aAc5Wlwj4gaBApIy@surfacebook.localdomain>


* Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> Mon, Apr 21, 2025 at 08:51:47PM +0200, Ingo Molnar kirjoitti:
> > Before:
> > 
> >         BIOS-provided physical RAM map:
> >         BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> >         BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> >         BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> >         BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable
> >         BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved
> >         BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
> >         BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
> >         BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> >         BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> >         BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
> > 
> > After:
> > 
> > 	BIOS-provided physical RAM map:
> > 	BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff]  639   KB kernel usable RAM
> > 	BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff]    1   KB reserved
> > 	BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff]  320   KB ...
> > 	BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff]   64   KB reserved
> > 	BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff]    1.9 GB kernel usable RAM
> > 	BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff]  144   KB reserved
> > 	BIOS-e820: [gap 0x0000000080000000-0x00000000afffffff]  768   MB ...
> > 	BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff]  256   MB reserved
> > 	BIOS-e820: [gap 0x00000000c0000000-0x00000000fed1bfff] 1005.1 MB ...
> > 	BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff]   16   KB reserved
> > 	BIOS-e820: [gap 0x00000000fed20000-0x00000000feffbfff]    2.8 MB ...
> > 	BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff]   16   KB reserved
> > 	BIOS-e820: [gap 0x00000000ff000000-0x00000000fffbffff]   15.7 MB ...
> > 	BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff]  256   KB reserved
> > 	BIOS-e820: [gap 0x0000000100000000-0x000000fcffffffff] 1008   GB ...
> > 	BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff]   12   GB reserved
> > 
> > Note how a 1-digit precision field is printed out if a range is
> > fractional in its largest-enclosing natural size unit.
> > 
> > So the "256 MB" and "12 GB" fields above denote exactly 256 MB and
> > 12 GB regions, while "1.9 GB" signals the region's fractional nature
> > and it being just below 2GB.
> > 
> > Printing E820 maps with such details visualizes 'weird' ranges
> > at a glance, and gives users a better understanding of how
> > large the various ranges are, without having to perform hexadecimal
> > subtraction in their minds.
> 
> ...
> 
> > +/*
> > + * Print out the size of a E820 region, in human-readable
> > + * fashion, going from KB, MB, GB to TB units.
> > + *
> > + * Print out fractional sizes with a single digit of precision.
> > + */
> > +static void e820_print_size(u64 size)
> > +{
> > +	if (size < SZ_1M) {
> > +		if (size & (SZ_1K-1))
> > +			pr_cont(" %4llu.%01llu KB", size/SZ_1K, 10*(size & (SZ_1K-1))/SZ_1K);
> > +		else
> > +			pr_cont(" %4llu   KB", size/SZ_1K);
> 
> I would add some spaces here and there for the sake of readability.

I think it's perfectly readable, skipping the whitespace for numeric 
literals is standard style. Linus himself does that occasionally, see:

  94a2bc0f611c ("arm64: add 'runtime constant' support")

  static inline void __runtime_fixup_ptr(void *where, unsigned long val)
  {
           __le32 *p = lm_alias(where);
           __runtime_fixup_16(p, val);
           __runtime_fixup_16(p+1, val >> 16);
           __runtime_fixup_16(p+2, val >> 32);
           __runtime_fixup_16(p+3, val >> 48);
           __runtime_fixup_caches(where, 4);
  }

Or:

  938df695e98d ("vsprintf: associate the format state with the format pointer")

  +       unsigned int shift = 32 - size*8;

which uses visual grouping to make arithmethic expressions more 
readable.

> 
> > +		return;
> > +	}
> > +	if (size < SZ_1G) {
> 
> Can be written in one line as
> 
> 	} else if (...) {

Done. (See delta patch below.)

> 
> Ditto for the rest.
> 
> > +		if (size & (SZ_1M-1))
> > +			pr_cont(" %4llu.%01llu MB", size/SZ_1M, 10*(size & (SZ_1M-1))/SZ_1M);
> > +		else
> > +			pr_cont(" %4llu   MB", size/SZ_1M);
> > +		return;
> > +	}
> > +	if (size < SZ_1T) {
> > +		if (size & (SZ_1G-1))
> > +			pr_cont(" %4llu.%01llu GB", size/SZ_1G, 10*(size & (SZ_1G-1))/SZ_1G);
> > +		else
> > +			pr_cont(" %4llu   GB", size/SZ_1G);
> > +		return;
> > +	}
> > +	if (size & (SZ_1T-1))
> > +		pr_cont(" %4llu.%01llu TB", size/SZ_1T, 10*(size & (SZ_1T-1))/SZ_1T);
> > +	else
> > +		pr_cont(" %4llu   TB", size/SZ_1T);
> > +}
> 
> Don't you want to use string_helpers.h provided API? 
> string_get_size().

I don't think string_get_size() knows the fine distinction between:

    BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff]  256   KB device reserved

and:

    BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff]  256.0 KB device reserved

"256 KB" is exactly 256 KB, while "256.0 KB" denotes a value that is a 
bit larger than 256 KB but rounds down to 256 KB at 1 KB granularity.

When reading platform boot logs it's useful to know when such values 
are exact, at a glance.

Thanks,

	Ingo

====================>
 arch/x86/kernel/e820.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7f600d32a999..67a477203c97 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -213,22 +213,19 @@ static void e820_print_size(u64 size)
 		else
 			pr_cont(" %4llu   KB", size/SZ_1K);
 		return;
-	}
-	if (size < SZ_1G) {
+	} else if (size < SZ_1G) {
 		if (size & (SZ_1M-1))
 			pr_cont(" %4llu.%01llu MB", size/SZ_1M, 10*(size & (SZ_1M-1))/SZ_1M);
 		else
 			pr_cont(" %4llu   MB", size/SZ_1M);
 		return;
-	}
-	if (size < SZ_1T) {
+	} else if (size < SZ_1T) {
 		if (size & (SZ_1G-1))
 			pr_cont(" %4llu.%01llu GB", size/SZ_1G, 10*(size & (SZ_1G-1))/SZ_1G);
 		else
 			pr_cont(" %4llu   GB", size/SZ_1G);
 		return;
-	}
-	if (size & (SZ_1T-1))
+	} else if (size & (SZ_1T-1))
 		pr_cont(" %4llu.%01llu TB", size/SZ_1T, 10*(size & (SZ_1T-1))/SZ_1T);
 	else
 		pr_cont(" %4llu   TB", size/SZ_1T);

  reply	other threads:[~2025-05-15 10:44 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21 18:51 [PATCH 00/29] x86/boot/e820: Assorted E820 table handling features and cleanups Ingo Molnar
2025-04-21 18:51 ` [PATCH 01/29] x86/boot/e820: Remove inverted boolean logic from the e820_nomerge() function name, rename it to e820_type_mergeable() Ingo Molnar
2025-04-21 18:51 ` [PATCH 02/29] x86/boot/e820: Simplify e820__print_table() a bit Ingo Molnar
2025-04-22  5:56   ` Mike Rapoport
2025-05-15 10:15     ` Ingo Molnar
2025-04-21 18:51 ` [PATCH 03/29] x86/boot/e820: Simplify the PPro Erratum #50 workaround Ingo Molnar
2025-04-22  6:29   ` Andy Shevchenko
2025-05-15 10:20     ` Ingo Molnar
2025-04-21 18:51 ` [PATCH 04/29] x86/boot/e820: Mark e820__print_table() static Ingo Molnar
2025-04-21 18:51 ` [PATCH 05/29] x86/boot/e820: Print gaps in the E820 table Ingo Molnar
2025-04-22  6:00   ` Mike Rapoport
2025-04-22  6:26     ` Andy Shevchenko
2025-05-15 10:23       ` Ingo Molnar
2025-04-22  6:42   ` Andy Shevchenko
2025-05-15 10:28     ` Ingo Molnar
2025-05-16  9:13       ` Andy Shevchenko
2025-04-21 18:51 ` [PATCH 06/29] x86/boot/e820: Make the field separator space character part of e820_print_type() Ingo Molnar
2025-04-21 18:51 ` [PATCH 07/29] x86/boot/e820: Print out sizes of E820 memory ranges Ingo Molnar
2025-04-22  6:38   ` Andy Shevchenko
2025-05-15 10:44     ` Ingo Molnar [this message]
2025-05-15 10:50       ` Ingo Molnar
2025-05-16  9:15       ` Andy Shevchenko
2025-04-22  6:53   ` Mike Rapoport
2025-05-15 11:00     ` Ingo Molnar
2025-04-21 18:51 ` [PATCH 08/29] x86/boot/e820: Print E820_TYPE_RAM entries as ... RAM entries Ingo Molnar
2025-04-22  6:31   ` Andy Shevchenko
2025-04-22  6:43     ` Mike Rapoport
2025-05-15 11:04       ` Ingo Molnar
2025-04-22  7:06   ` Mike Rapoport
2025-05-15 11:19     ` [PATCH 30/29] x86/boot/e820: Unify e820_print_type() and e820_type_to_string() Ingo Molnar
2025-04-21 18:51 ` [PATCH 09/29] x86/boot/e820: Call the PCI gap a 'gap' in the boot log printout Ingo Molnar
2025-04-21 18:51 ` [PATCH 10/29] x86/boot/e820: Use 'u64' consistently instead of 'unsigned long long' Ingo Molnar
2025-04-22  6:44   ` Andy Shevchenko
2025-05-15 11:20     ` Ingo Molnar
2025-04-21 18:51 ` [PATCH 11/29] x86/boot/e820: Remove pointless early_panic() indirection Ingo Molnar
2025-04-21 18:51 ` [PATCH 12/29] x86/boot/e820: Clean up confusing and self-contradictory verbiage around E820 related resource allocations Ingo Molnar
2025-04-21 18:51 ` [PATCH 13/29] x86/boot/e820: Improve e820_print_type() messages Ingo Molnar
2025-04-21 18:51 ` [PATCH 14/29] x86/boot/e820: Clean up __e820__range_add() a bit Ingo Molnar
2025-04-22 10:10   ` Andy Shevchenko
2025-05-15 11:21     ` Ingo Molnar
2025-04-21 18:51 ` [PATCH 15/29] x86/boot/e820: Clean up __refdata use " Ingo Molnar
2025-04-21 18:51 ` [PATCH 16/29] x86/boot/e820: Remove unnecessary header inclusions Ingo Molnar
2025-04-21 18:51 ` [PATCH 17/29] x86/boot/e820: Standardize e820 table index variable names under 'idx' Ingo Molnar
2025-04-22 10:23   ` Andy Shevchenko
2025-05-15 11:32     ` [PATCH 31/29] x86/boot/e820: Move index increments outside accessors in e820__update_table() Ingo Molnar
2025-05-15 11:37     ` [PATCH 17/29] x86/boot/e820: Standardize e820 table index variable names under 'idx' Ingo Molnar
2025-04-21 18:51 ` [PATCH 18/29] x86/boot/e820: Change struct e820_table::nr_entries type from __u32 to u32 Ingo Molnar
2025-04-21 18:51 ` [PATCH 19/29] x86/boot/e820: Standardize e820 table index variable types under 'u32' Ingo Molnar
2025-04-22 15:13   ` Andy Shevchenko
2025-05-15 11:39     ` Ingo Molnar
2025-04-21 18:52 ` [PATCH 20/29] x86/boot/e820: Clean up e820__setup_pci_gap()/e820_search_gap() a bit Ingo Molnar
2025-04-22 16:37   ` Andy Shevchenko
2025-05-15 11:44     ` Ingo Molnar
2025-04-21 18:52 ` [PATCH 21/29] x86/boot/e820: Change e820_search_gap() to search for the highest-address PCI gap Ingo Molnar
2025-04-21 18:52 ` [PATCH 22/29] x86/boot/e820: Rename gap_start/gap_size to max_gap_start/max_gap_start in e820_search_gap() et al Ingo Molnar
2025-04-21 18:52 ` [PATCH 23/29] x86/boot/e820: Simplify & clarify __e820__range_add() a bit Ingo Molnar
2025-04-21 18:52 ` [PATCH 24/29] x86/boot/e820: Standardize __init/__initdata tag placement Ingo Molnar
2025-04-21 18:52 ` [PATCH 25/29] x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables Ingo Molnar
2025-04-21 18:52 ` [PATCH 26/29] x86/boot/e820: Remove e820__range_remove()'s unused return parameter Ingo Molnar
2025-04-21 18:52 ` [PATCH 27/29] x86/boot/e820: Simplify the e820__range_remove() API Ingo Molnar
2025-04-22 16:41   ` Andy Shevchenko
2025-05-15 11:49     ` Ingo Molnar
2025-04-21 18:52 ` [PATCH 28/29] x86/boot/e820: Make sure e820_search_gap() finds all gaps Ingo Molnar
2025-04-21 18:52 ` [PATCH 29/29] x86/boot/e820: Treat non-type-2 'reserved' E820 region types as E820_TYPE_RESERVED Ingo Molnar
2025-04-25  3:55   ` H. Peter Anvin
2025-05-15 10:04     ` [PATCH -v2 29/29] x86/boot/e820: Introduce E820_TYPE_13 and treat it as a device region Ingo Molnar
2025-04-22  6:58 ` [PATCH 00/29] x86/boot/e820: Assorted E820 table handling features and cleanups Arnd Bergmann
2025-05-15 11:56   ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aCXFdvWiNW94F24R@gmail.com \
    --to=mingo@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=arnd@kernel.org \
    --cc=bp@alien8.de \
    --cc=dwmw@amazon.co.uk \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.