linux-kernel - Re: [PATCH v5 2/3] x86: probe memory block size advisement value during mm init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZyT_fLBsVLlcnYNi@PC2K9PVX.TheFacebook.com>
Date: Fri, 1 Nov 2024 12:19:08 -0400
From: Gregory Price <gourry@...rry.net>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, linux-mm@...ck.org,
	linux-cxl@...r.kernel.org, Jonathan.Cameron@...wei.com,
	dan.j.williams@...el.com, rrichter@....com, Terry.Bowman@....com,
	dave.jiang@...el.com, ira.weiny@...el.com,
	alison.schofield@...el.com, dave.hansen@...ux.intel.com,
	luto@...nel.org, peterz@...radead.org, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, rafael@...nel.org, lenb@...nel.org,
	david@...hat.com, osalvador@...e.de, gregkh@...uxfoundation.org,
	akpm@...ux-foundation.org, rppt@...nel.org
Subject: Re: [PATCH v5 2/3] x86: probe memory block size advisement value
 during mm init

On Fri, Nov 01, 2024 at 04:51:47PM +0100, Borislav Petkov wrote:
> On Fri, Nov 01, 2024 at 09:47:04AM -0400, Gregory Price wrote:
> > Systems with hotplug may provide an advisement value on what the
> > memblock size should be.  Probe this value when the rest of the
> > configuration values are considered.
> > 
> > The new heuristic is as follows
> > 
> > 1) set_memory_block_size_order value if already set (cmdline param)
> > 2) minimum block size if memory is less than large block limit
> > 3) if no hotplug advice: Max block size if system is bare-metal,
> >    otherwise use end of memory alignment.
> > 4) if hotplug advice: lesser of advice and end of memory alignment.
> > 
> > Suggested-by: David Hildenbrand <david@...hat.com>
> > Signed-off-by: Gregory Price <gourry@...rry.net>
> > Acked-by: David Hildenbrand <david@...hat.com>
> > ---
> >  arch/x86/mm/init_64.c | 15 ++++++++++-----
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> > index ff253648706f..f1a495e998ce 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -1452,16 +1452,21 @@ static unsigned long probe_memory_block_size(void)
> >  	}
> >  
> >  	/*
> > -	 * Use max block size to minimize overhead on bare metal, where
> > -	 * alignment for memory hotplug isn't a concern.
> > +	 * When hotplug alignment is not a concern, maximize blocksize
> > +	 * to minimize overhead. Otherwise, align to the lesser of advice
> > +	 * alignment and end of memory alignment.
> >  	 */
> > -	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
> > +	bz = memory_block_advised_max_size();
> > +	if (!bz) {
> >  		bz = MAX_BLOCK_SIZE;
> > -		goto done;
> > +		if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> 
> s/boot_cpu_has/cpu_feature_enabled/
> 
> while at it.
> 

I don't personally understand the implications of this switch off hand,
probably warrants a separate patch submission if you think it's important
given the original logic is boot_cpu_has and I don't want to increase
scope change here.

~Gregory

> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette