[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Questions about the use of idle_vcpu[]

On Mon, Jan 18, 2016 at 6:00 AM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> On Mon, 2016-01-18 at 10:47 +0000, George Dunlap wrote:
> > On Fri, Jan 15, 2016 at 1:04 AM, Tianyang Chen <tiche@xxxxxxxxxxxxxx>
> >
> > > If an idle vcpu is picked, the ret.time is set accordingly in both
> > > credit
> > > and credit2 by checking whether snext is idle. if so, credit
> > > returns -1 and
> > > credit2 returns 2ms. However, there is no corresponding code in the
> > > RTDS
> > > scheduler to handle this. When an idle_vcpu is picked, the value of
> > > ret.time
> > > would be 0 and the scheduler would be invoked again. What is the
> > > logic
> > > behind this?
> >
> > No real logic, as far as I can tell. :-)  The ret.time return value
> > tells the generic scheduling code when to set the next scheduler
> > timer.  According to the comment in xen/common/schedule.c:schedule(),
> > returning a negative value means "don't bother setting a timer"
> > (e.g.,
> > no time limit).  So credit1 does the right thing.
> >
> It does.

Then the RTDS is doing *incorrectly* right now. :-(

> > It looks like credit2's behavior will probably prevent the processor
> > from going into deeper power-saving states, and rtds' behavior might
> > cause it to essentially busy-wait.
> >
> RTDS behavior is broken in many respect, including this,
> and in fact,
> Meng and Tianyang are sending patches already to fix it (I'll let you
> guys have my comments shortly :-P).

Right. Tianyang and I are working on changing it from quantum driven
model to event-driven (or called timer-driven) model. Tianyang sent
out the first-version patch, but that version has some problems. He is
working on the second version now.

Hi Dario,
Tianyang is working on the second version right now.
If you could have a quick look at our discussion in that thread and
points out the "serious" issues in the decision, that will be great!
We won't repeat the error again and again in the following versions.
As to the minor issues, we could refine it in the second version.
(I'm just thinking about how to save your time to have this done. For
the obvious things that I can handle, I will do it and avoid "wasting"
you time. For the design choices that we are unclear, we definitely
need your insights/commands. ;-) )

> Credit2, AFAICR, could also avoid _always_ re-setting the timer, but it
> does need to do that at least a few times, even when idle is selected,
> because of the dynamic load tracking mechanism it includes. In fact,
> that is based on a 'decaying average', which in turns relies on
> csched2_schedule() to run and update the statistics, even when the cpu
> is idle. If we don't do that, the load tracking mechanism will never
> see that the cpu (well, it's actually the runqueue) is idle, and the
> load will never go down! :-/
> I've got patches for:
>  - extending the dynamic load tracking logic to all scheduler (iff
>    they want to use it, of course)
>  - only call {csched,csched2,rtds}_schedule() if necessary. That
>    means, if the pcpu/runqueue is idle (and if the dynamic tracking is
>    in use by the specific scheduler), only return a positive value
>    and set the timer if the dynamic load is >0, to allow it to decay
>    (if the pcpu/runqueue stays idle enough).
> But they are on hold, while I'm finishing some other work.
> > Dario / Meng, am I reading things right?  If so, we should probably
> > fix that...
> >
> Yep, and in fact, we're on it already. I hope to be able to post my
> patches soon. :-)

Hi George,
Yes, you are right. The current RTDS should not return 0 when the idle
VCPU is picked. I think it should do as what the credit does, i.e.,
returning a negative value to avoid arming the timer.
Right now, we are working on changing RTDS to event-driven model. We
will fix this in the next version of the patch.

If needed, we can send out a separate patch to fix this specific issue
(i.e. it should return negative value when idle vcpu is picked.) I'm
ok with either way. Which way do you guys prefer?



Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.