[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: credit1: fix tickling when it happens from a remote pCPU
On Thu, 2015-09-24 at 03:29 -0600, Jan Beulich wrote: > > > > On 24.09.15 at 06:31, <dario.faggioli@xxxxxxxxxx> wrote: > > --- a/xen/common/sched_credit.c > > +++ b/xen/common/sched_credit.c > > #define csched_balance_mask (CSCHED_PCPU(smp_processor_id()) > > ->balance_mask) > > > > +#define csched_balance_mask_cpu(c) (CSCHED_PCPU(c)->balance_mask) > > csched_runq_steal() gets called with peer_cpu's runqueue lock held > afaics, but uses smp_processor_id()'s balance_mask. I.e. it looks to > me that what JÃrgen suggested as an option is actually a requirement. > And I'm very much agreeable on taking his suggestion, because I actually like it. Correctness should not be an issue, though. In fact, here is the story about csched_runq_steal(): schedule() cpu = smp_processor_id() lock = pcpu_schedule_lock_irq(cpu); sched = this_cpu(scheduler); next_slice = sched->do_schedule(sched, ...); | --> csched_schedule() cpu = smp_processor_id(); snext = csched_load_balance(..., cpu, ...); peer_cpu = xxx; lock = pcpu_schedule_trylock(peer_cpu); speer = csched_runq_steal(peer_cpu, cpu, ...); csched_balance_cpumask(..., csched_balance_mask); pcpu_schedule_unlock(lock, peer_cpu); pcpu_schedule_unlock_irq(lock, cpu); So, we can safely use smp_processor_id()'s scratch space, as we own its runqueue lock too. In any case, thanks a lot for having a look. 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |