Re: Questions about the use of idle_vcpu[]

[Tianyang Chen <tiche@seas.upenn.edu>]

On 1/18/2016 11:07 AM, Meng Xu wrote:
> On Mon, Jan 18, 2016 at 6:00 AM, Dario Faggioli
> <dario.faggioli@citrix.com> 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@seas.upenn.edu>
>>>
>>>> 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