lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM
    From
    Date
    On Mon, 2009-05-11 at 17:51 +0300, Avi Kivity wrote:
    > Ingo Molnar wrote:
    > > * Avi Kivity <avi@redhat.com> 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?



    \
     
     \ /
      Last update: 2009-05-11 17:07    [W:0.034 / U:0.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site