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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Monday, August 03, 2015 6:02 PM
> To: Wu, Feng
> Cc: xen-devel@xxxxxxxxxxxxx; Keir Fraser; Jan Beulich; Andrew Cooper; Tian,
> Kevin; George Dunlap
> Subject: Re: [v4 16/17] vmx: Add some scheduler hooks for VT-d posted
> interrupts
> 
> 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.

Thanks for the elaborate description, it is very helpful.

Thanks,
Feng

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