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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Fri, Jan 15, 2016 at 1:04 AM, Tianyang Chen <tiche@xxxxxxxxxxxxxx> wrote:
> Hello,
>
> I'm confused by the use of idle_vcpu[] in Xen schedulers. In credit, credit2
> and rtds schedulers, they are used in conjunction with variable
> "tasklet_work_scheduled" like this:
>
> if ( tasklet_work_scheduled )
> {
>     snext = #_VCPU(idle_vcpu[cpu]);
>     ....
> }
>
> The idle_vcpu array is initialized in cpu_schedule_up() and indeed they are
> set in corresponding alloc_vdata() to have IDLE_CREDIT and 0 weight or
> DEFAULT_PERIOD and 0 budget.
>
> The value of tasklet_work_scheduled comes from scheduler.c interface.
> According to the comments in sched_credit2.c, if there's tasklet work to do,
> we want to chose the idle vcpu for this processor, and mark the current for
> delayed runqueue add. Can someone elaborate the reason why an idle vcpu
> should be picked? What does an idle_vcpu do to a tasklet? I feel like I'm
> missing something here.

do_tasklet() is called from idle_loop() (see xen/arch/{arm,x86}/domain.c).

Xen doesn't have kernel threads, so when it has tasks which are
prompted by an interrupt but need to be done in a non-interrupt
context, it switches to the "idle" vcpu and does them there.

> 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 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.

Dario / Meng, am I reading things right?  If so, we should probably fix that...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel