Messages in this thread | | | Date | Wed, 13 Aug 2008 21:49:44 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug |
| |
* Jeremy Fitzhardinge (jeremy@goop.org) wrote: > H. Peter Anvin wrote: >> I believe this should be okay. In 32-bit mode some of the security and >> hypervisor frameworks want to set segment limits, but I don't believe they >> ever would set DS and SS inconsistently, or that we'd handle a #GP versus >> an #SS differently (segment violations on the stack segment are #SS, not >> #GP.) To be 100% sure we'd have to pick apart the modr/m byte to figure >> out what the base register is but I think that's total overkill. > > The kernel sets ds and ss to the same selector, so they're always going to > have the same underlying descriptor. > > My only concern is whether there are any locked instructions which are > explicitly using a cs: override for those odd corners of the kernel. I > don't think so. > > That said, I wonder how useful it is to do the SMP->UP code transition. > How often does a kernel go from being SMP to UP in a situation where we > really care about the performance? And that won't be shortly be becoming > SMP again anyway? >
A virtualized guest kernel could use that to limit its use of the overall machine CPU resources in different time periods. Policies can determine how many physical CPU a virtual machine can be tied to, and that may change depending on e.g. the workload or time of day. Having the ability to efficiently switch to UP for a long period of time seems important in this use-case.
Mathieu
> J
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |