RE: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives

Kaplan, David
2025-10-30T15:49:27Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Nikolay Borisov <nik.borisov@suse.com>
> Sent: Thursday, October 30, 2025 10:43 AM
> To: Kaplan, David <David.Kaplan@amd.com>; David Laight
> <david.laight.linux@gmail.com>
> Cc: Juergen Gross <jgross@suse.com>; Thomas Gleixner <tglx@linutronix.de>;
> Borislav Petkov <bp@alien8.de>; Peter Zijlstra <peterz@infradead.org>; Josh
> Poimboeuf <jpoimboe@kernel.org>; Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com>; Ingo Molnar <mingo@redhat.com>; Dave
> Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; Alexander Graf <graf@amazon.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; linux-kernel@vger.kernel.org; Vlastimil Babka
> <vbabka@suse.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