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

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Nikolay Borisov <nik.borisov@xxxxxxxx>
> Sent: Thursday, October 30, 2025 10:43 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>; David Laight
> <david.laight.linux@xxxxxxxxx>
> Cc: Juergen Gross <jgross@xxxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx>;
> Borislav Petkov <bp@xxxxxxxxx>; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Josh
> Poimboeuf <jpoimboe@xxxxxxxxxx>; Pawan Gupta
> <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Dave
> Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H . Peter Anvin
> <hpa@xxxxxxxxx>; Alexander Graf <graf@xxxxxxxxxx>; Boris Ostrovsky
> <boris.ostrovsky@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Vlastimil Babka
> <vbabka@xxxxxxx>
> 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