Hi, Peter, Longman, > On Apr 3, 2019, at 12:01 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Wed, Apr 03, 2019 at 11:39:09AM -0400, Alex Kogan wrote: > >>>> The patch that I am looking for is to have a separate >>>> numa_queued_spinlock_slowpath() that coexists with >>>> native_queued_spinlock_slowpath() and >>>> paravirt_queued_spinlock_slowpath(). At boot time, we select the most >>>> appropriate one for the system at hand. >> Is this how this selection works today for paravirt? >> I see a PARAVIRT_SPINLOCKS config option, but IIUC you are talking about a different mechanism here. >> Can you, please, elaborate or give me a link to a page that explains that? > > Oh man, you ask us to explain how paravirt patching works... that's > magic :-) > > Basically, the compiler will emit a bunch of indirect calls to the > various pv_ops.*.* functions. > > Then, at alternative_instructions() <- apply_paravirt() it will rewrite > all these indirect calls to direct calls to the function pointers that > are in the pv_ops structure at that time (+- more magic). Trying to resume this work, I am looking for concrete steps required to integrate CNA with the paravirt patching. Looking at alternative_instructions(), I wonder if I need to add another call, something like apply_numa() similar to apply_paravirt(), and do the patch work there. Or perhaps I should “just" initialize the pv_ops structure with the corresponding numa_queued_spinlock_slowpath() in paravirt.c? Also, the paravirt code is under arch/x86, while CNA is generic (not x86-specific). Do you still want to see CNA-related patching residing under arch/x86? We still need a config option (something like NUMA_AWARE_SPINLOCKS) to enable CNA patching under this config only, correct? Thanks in advance, — Alex
