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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux