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

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





On 1/18/2016 11:07 AM, Meng Xu wrote:
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. :-(


George: Thanks. After looking at idle_loop() it makes sense now. Even though an idle vcpu won't tell scheduler timer when to fire next time, do_tasklet() checks if all tasklets on the list are finished and then raise SCHEDULE_SOFTIRQ.



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

Dario: I had some discussion with Meng recently and the second version will soon come out. You can directly comment on it if that saves you some time.

Thanks,
Tianyang

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


 


Rackspace

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