On Mon, 2016-02-08 at 14:04 -0500, Tianyang Chen wrote:
> 
> On 2/8/2016 6:27 AM, Dario Faggioli wrote:
> > 
> > I don't really follow, but I have the feeling that you're making it
> > sound more complicated like it is in reality... :-)
> > 
> 
> So my reasoning is that, when sleep() is called in sched_rt.c, a
> vcpu 
> will need to be taken off from the replenishment event queue.
> However, a 
> vcpu can be put to sleep/not-runnable without even calling sleep(), 
>
Well, sure... for instance, it can block.

> which corresponds to a later "spurious wakeup". Is there any way
> that 
> RTDS can know when this happens? 
>
There is no way no one can tell what will happen in future but,
luckily, we don't need to care! There is no such thing as the
correspondence between spurious wakeups and sleeps.

> If not, in rt_vcpu_wake(), it needs to 
> check, in all situations, if a vcpu is on the replenishment event
> queue 
> or not. If not, add it back. I'm I right?
> 
> vcpu running      --> sleep(), taken off from replq   
> vcpu on queue     --> sleep(), taken off from replq
> vcpu not on queue --> sleep(), taken off from replq
> 
No. What happens is, more or less, like this:

 - sleep  : take off from runq, take off from replq
 - wakeup : put back in runq, put back in replq
 - wakeup : already on runq, already on replq ==> nothing!
 ...
 [becomes running]
 ...
 - wakeup : on a cpu, already on replq ==> nothing!

> However,
> 
> vcpu running/on queque/not on queue --> just not runnable anymore
> (still 
> on replq) --> spurious wakeup (still on replq)
> 
> vcpus shouldn't be added back to replq again.
> 
Exactly, and in fact, you do nothing. :-)

> So in all cases, rt_vcpu_wake() always need to check if a vcpu is on
> the 
> replq or not.
> 
Eheh... looks like we agree on the fact that we disagree. :-)

> Now I think because of the addition of a replenishment queue,
> spurious 
> wake up cannot be simply treated as NOP. Just like V4, the "Out"
> label 
> basically maintains the replenishment queue.
> 
I do think so. I also think that we may need to think about the
blocking case (i.e., whether to do something for removing the vcpu from
the replenishment queue or not). But really...

> Anyways, I agree it's gonna be easier to reason on v5 where all
> changes 
> are applied.
> 
... let's do this! :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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

Reply via email to