Re: [PATCH 1/10] Cr4 is valid on some 486s

[Zachary Amsden <zach@vmware.com>]

Linus Torvalds wrote:

> On Mon, 14 Nov 2005, Gerd Knorr wrote:
>  
>
> > Throwing another patch into the discussion ;)
> >    
>
> Ouch, this one is really ugly.
>
> If you want to go this way, then you should instead add an X86_FEATURE_SMP 
> that gets cleared on UP and on SMP with just one core (and detect when CPU 
> hotplug ain't gonna happen ;), and then do
>
> 	#ifdef CONFIG_SMP
> 	#define smp_alternative(x,y) alternative(x,y,X86_FEATURE_SMP)
> 	#else
> 	#define smp_alternative(x,y) asm(x)
> 	#endif
>
> or something similar, instead of creating a totally new infrastructure to 
> do the thing that "alternative()" already does.
>
> (Yeah, the above doesn't really work, since usually the SMP form is the 
> longer one, and "alternative()" wants the long complex one first. So maybe 
> the x86 feature needs to be "X86_FEATURE_UP" instead, since it's now a 
> "feature" to only have one core ;)
>  

It seems that SMP vs. UP lock / spinlock overhead is relevant even for 
future, multi-core CPUs in a virtualization context, as the notion of 
hotplug here is based on scheduling constraints of the virtualization 
engine, and the kernel can quite readily end up with only one VCPU.

But it also seems that there are separate, competing mechanisms for 
implementing this dynamic code change, which is undesirable.  The notion 
of boot-time dynamic code change for SMP is useful for native hardware.  
Run-time dynamic code change is useful for virtual hardware, and 
minimally useful for hardware CPU hotplug.  Run-time dynamic code change 
is also useful on virtual hardware if you consider live kernel 
migrations across CPUs from different vendors, or with different 
features.  Again, this is minimally useful for hardware CPU hotplug.

But in essence, there should be one nice way to encapsulate this code 
modification that lives for both run-time and boot-time code.  The 
boot-time modifiers can jettison the alternative tables, and the 
run-time guys (which might include CPU hotplug) can keep those 
alternatives around so they can be unapplied later.  One can even 
imagine more complex alternative features (if I have SSE2, use code X, 
but if SSE3 is available use code Y, else fall back to code Z) being 
useful at some point.

Both points combined are a basic argument for providing an alternative 
choice function in apply_alternatives, which takes as input the 
alternative specification, and returns a pointer to the chosen code.  
This function can be driven by dynamic data (number of plugged CPUs), or 
by static specifications (feature spec in the alternative section).

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/