lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM
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.

> And only do it if there's other tasks running on this CPU or
> so.
>

What would happen if there weren't? I'd guess the task would continue
running (but with a warped vruntime)?

> _That_ would be pretty efficient, and would do the right thing when
> two (or more) vcpus run on the same CPU, and it would also do the
> right thing if there are repeated VM-exits due to pause filtering.
>
> Please dont even think about using yield for this though - that will
> just add a huge hit to this task and wont result in any sane
> behavior - and yield is bound to some historic user-space behavior
> as well.
>
> A gradual and linear back-off from the current timeline is more of a
> fair negotiation process between vcpus and results in more or less
> sane (and fair) scheduling, and no unnecessary looping.
>
> You could even do an exponential backoff up to a limit of 1-10 msecs
> or so, starting at 100 usecs.
>

Good idea, it eliminates another variable to be tuned.

--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2009-05-11 16:55    [W:0.096 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site