Re: [Xen-devel] [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling.

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2015-07-08 at 20:46 -0700, Meng Xu wrote:
> 2015-07-08 1:01 GMT-07:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:

> But after thinking twice, maybe runq approach is a better way since it
> just make the position information more meaningful. As you described
> in the previous email, we can compare the position of a vcpu inserted
> into the runq with the number of pCPUs so as to quickly know which
> pCPU to tickle.
> 
> > I appreciate this is a rather big  change
> > (although, perhaps it looks bigger said than done), but I think it could
> > be worth pursuing.
> 
> It is worth pursuing since it simplify the cpu tickling process a lot.
> 
Great! :-)

> > I think that I'd like to know why you think adding another queue is
> > necessary, instead of just leaving the vCPUs in the actual runq. Is
> > there something bad about that which I'm missing?
> 
> Actually, nothing bad. I just recalled the situation when we split a
> runq to runq and delpetedq. I was thinking it might be the case here
> as well. (Yes, it is different here since we can get more useful
> information to tickle cpu if we put vCPUs into runq instead of adding
> one more queue.) :-)
> >
IMO, having things split could be beneficial for scalability *BUT* only
in case we also get rid of the big spin lock. Until we won't get there
(which is not that urgent) using the same queue is fine.

For runq and depletedq, the same applies, with the small difference
that, since both need to be sorted, having two actual queues looks
easier than having just one with a marker, but that's only an
implementation detail, it's fine however it is. OTOH, in this case,
using runq only, without introducing another queue, actually helps
making things simpler!

> > Yes, but if we use two queues, we defeat at least part of this
> > optimization/simplification.
> 
> Agree. Thanks! :-D
> 
Perfect. Looking also at Dagaen replies, it sounds like we have a plan!
Looking forward to see the code! :-D

> > I don't think the added space would be a problem, but I don't see why we
> > need it.
> 
> If we don't add another queue, no extra space. So we get free lunch here. :-)
> 
Yeah, but let's not exaggerate with free lunches, I'm trying to loose
some weight! :-P

Thanks and 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel