Re: [Xen-devel] credit scheduler and HYPERVISOR_yield()

["George Dunlap" <gdunlap@xxxxxxxxxxxxx>]

The code does what it's designed to -- put the current vcpu behind any
vcpus of equal priority.

But that behavior isn't always the ideal, specifically in situations
like John describes.  The credit scheduler has two basic priorities --
TS_UNDER (hasn't yet used all its credits) and TS_OVER (used all its
credits).  The scheduler switches between these two based on how much
cpu time a vcpu has actually had compared to how much it's allocated.
This is a very clever way to make sure that each vcpu gets its fair
share, but that spare cycles are still used effectively.

What this means in the case of a yield(), unfortunately, is that If a
given vcpu is the only vcpu on its processor with credits left, all it
can do is burn up its extra credits spinning or calling yield() to no
effect.

A simple option would be, for the credit scheduler, to temporarily
reduce the priority from TS_UNDER to TS_OVER.  This will cause it to
actually yield if there's any other vcpus that can run.  The next time
accounting is done, the priority will be reset, and it should get more
time because of the time it's given up.

Thoughts?

 -George

On 10/9/07, John Levon <levon@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 09, 2007 at 09:06:14AM +0200, Emmanuel Ackaouy wrote:
>
> > The expected behavior of yield() (or any schedule operation really) is
> > that the current VCPU will be placed on the runq behind all VCPUs of
> > equal or greater priority.
> >
> > Looking at __runq_insert() in sched_credit.c, it looks correct to me in
> > that respect.
> >
> > Can you clarify what's going wrong?
>
> It looks fine... no idea how I misread the code.
>
> sorry,
> john
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel