[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <LV3PR12MB9265382A2DC4A7840E21943194FBA@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 30 Oct 2025 15:49:22 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Nikolay Borisov <nik.borisov@...e.com>, David Laight
	<david.laight.linux@...il.com>
CC: Juergen Gross <jgross@...e.com>, Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>, Josh
 Poimboeuf <jpoimboe@...nel.org>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H .
 Peter Anvin" <hpa@...or.com>, Alexander Graf <graf@...zon.com>, Boris
 Ostrovsky <boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Vlastimil Babka <vbabka@...e.cz>
Subject: RE: [RFC PATCH 34/56] x86/alternative: Save old bytes for
 alternatives
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Nikolay Borisov <nik.borisov@...e.com>
> Sent: Thursday, October 30, 2025 10:43 AM
> To: Kaplan, David <David.Kaplan@....com>; David Laight
> <david.laight.linux@...il.com>
> Cc: Juergen Gross <jgross@...e.com>; Thomas Gleixner <tglx@...utronix.de>;
> Borislav Petkov <bp@...en8.de>; Peter Zijlstra <peterz@...radead.org>; Josh
> Poimboeuf <jpoimboe@...nel.org>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; Alexander Graf <graf@...zon.com>; Boris Ostrovsky
> <boris.ostrovsky@...cle.com>; linux-kernel@...r.kernel.org; Vlastimil Babka
> <vbabka@...e.cz>
> Subject: Re: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 10/30/25 16:39, Kaplan, David wrote:
> <snip>
>
> >>
> >
> > Yes, there is an 8B pointer to each allocation (although I didn't include that in the
> number above).
> >
> > There's a number of ways to optimize this, doing a single 'big buffer' with perhaps
> a 32-bit index seems rather straightforward.  And maybe there are then further ways
> to squeeze this.  But I think we're really talking about a small amount of memory,
> especially compared to the other overhead noted above.
> >
>
>
> I spoke with Vlastimil who's a lot more familiar with MM and he said
> that allocations made early in the boot are likely to fall within the
> same 2mb block so actually what we are discussing here might very well
> fall within  "premature optimisation" land.
>
Ah, that's good to know.  I'll leave it as-is for now.
Thanks!
--David Kaplan
Powered by blists - more mailing lists
 
