On Mon, 2009-05-11 at 17:51 +0300, Avi Kivity wrote: > Ingo Molnar wrote: > > * Avi Kivity <avi@xxxxxxxxxx> wrote: > > > > > >>> I.e. this is a somewhat poor solution as far as scheduling goes. > >>> But i'm wondering what the CPU side does. Can REP-NOP really take > >>> thousands of cycles? If yes, under what circumstances? > >>> > >> The guest is running rep-nop in a loop while trying to acquire a > >> spinlock. The hardware detects this (most likely, repeated > >> rep-nop with the same rip) and exits. We can program the loop > >> count; obviously if we're spinning for only a short while it's > >> better to keep spinning while hoping the lock will be released > >> soon. > >> > >> The idea is to detect that the guest is not making forward > >> progress and yield. If I could tell the scheduler, you may charge > >> me a couple of milliseconds, I promise not to sue, that would be > >> ideal. [...] > >> > > > > Ok, with such a waiver, who could refuse? > > > > This really needs a new kernel-internal scheduler API though, which > > does a lot of fancy things to do: > > > > se->vruntime += 1000000; > > > > i.e. add 1 msec worth of nanoseconds to the task's timeline. (first > > remove it from the rbtree, then add it back, and nice-weight it as > > well) > > I suspected it would be as simple as this. Is that thread guaranteed to run as SCHED_OTHER? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
