* 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) And only do it if there's other tasks running on this CPU or
so.
_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.
Ingo
--
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
