Re: [Xen-users] whether xen scheduler supports preemption

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mer, 2013-06-26 at 07:37 +0800, åä wrote:
> å 2013-06-26 07:27:26ï"Dario Faggioli" <dario.faggioli@xxxxxxxxxx> åéï
> >Regarding what you're saying about the "preemption function", I'm sorry,
> >but I cannot parse that part of the sentence... What do you mean by
> >"which part decides it has the preemption function"?
> My meaning is that which code decides the xen scheduler has the preemption 
> ability. 
>
Well, the point is it is hard to restrict to a single function (or
anything like that) something like what you call the "preemption
ability". I mean, when you design a scheduler you either design it to be
preemptible or not, and this design choice reflects in many places in
the code... Anyways...

> In the sched_credit.c file, there is a function, 
> csched_vcpu_wake()->__runq_tickle(), in the function, __runq_tickle(), at the 
> end, there is the following code:
> 
... Yes, that is at least most of it. In fact, when a vcpu wakes up, it
is added to a specific runq, and the 'tickling' mechanism is there right
to ensure that the said vcpu starts to run as soon as possible, either
if there are idle pcpus, or the running vcpus have lower priority, the
latter case being the definition of preemption.

> if ( !cpumask_empty(&mask) )
>         cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);
> It will raise SCHEDULE_SOFTIRQ interrupt, whether here decides it has the 
> preemption ability, or other parts? 
>
Again, this is probably the most important part of it. The scheduler
runs every time the SCHEDULE_SOFTIRQ interrupt is raised (for a given
pcpu), and the fact that this happens as a consequence of a vcpu waking
up, is what make this particular path a (possible) 'preemption point'.

If you, for instance, avoid raising the SCHEDULE_SOFTIRQ for busy pcpus
(I would still tickle the idle ones, or you'll get funny results! :-O),
you definitely are making the (credit) scheduler less preemptible.

Of course, wake-ups is not the only cause of SCHEDULE_SOFTIRQ being
raised. E.g., it fires periodically at the scheduling time slice
boundaries. If you want to avoid vcpus being interrupted by others with
higher priority for this case too, you probably have more paths to tweak
than just the csched_vcpu_wake() function.

> If it raise a SCHEDULE_SOFTIRQ interrupt, when will deal with this software 
> interrupt? In time or the current vcpu gives up the physical cpu?  
> 
And here I'm failing at understanding what you mean again... When a
SCHEDULE_SOFTIRQ is raised for a given pcpu, that pcpu will deal with
it, well, ASAP (look at how softirqs & tasklets work in the hypervisor
source code). What do you mean by "give up the physical cpu"?

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-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users