Re: [Xen-devel] [v4 16/17] vmx: Add some scheduler hooks for VT-d posted interrupts

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2015-08-03 at 01:36 +0000, Wu, Feng wrote:
> > -----Original Message-----
> > From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]

> > It's safe in any case. In fact, the spinlock will  prevent both the
> > vcpu's processor to schedule, as well as any other processors to steal
> > the waking vcpu from the runqueue to run it.
> 
> Good to know this. For " as well as any other processors to steal
> the waking vcpu from the runqueue to run it ", could you please show
> some hints in the code side, so I can better understand how this can
> be protected by the spinlock. Thank you!
> 
Sure. For instance, for the Credit1 scheduler, look at
csched_load_balance(). vcpus are moved from one runqueue to another by
means of csched_runq_steal() which, as you can see, is called only if
the spinlock for the pcpu from where we want to try stealing has been
successfully acquired:

    spinlock_t *lock = pcpu_schedule_trylock(peer_cpu);

    if ( !lock )
    {
        SCHED_STAT_CRANK(steal_trylock_failed);
        peer_cpu = cpumask_cycle(peer_cpu, &workers);
        continue;
    }

    /* Any work over there to steal? */
    speer = cpumask_test_cpu(peer_cpu, online) ?
         csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL;
    pcpu_schedule_unlock(lock, peer_cpu);

Same happen in Credit2. Check choose_cpu(), and you'll fine similar
reasoning and code.

In RTDS, finally, there's just one runqueue, for all pcpus, so each time
each one of them has to schedule it has to take the only one spinlock
protecting it.

Hope this helped.

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