Re: [PATCH 6/6] xen: sched: optimize exclusive pinning case (Credit1 & 2)

[George Dunlap <george.dunlap@citrix.com>]

On Fri, Jul 21, 2017 at 8:55 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On Fri, 2017-07-21 at 18:19 +0100, George Dunlap wrote:
>> On 06/23/2017 11:55 AM, Dario Faggioli wrote:
>> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>> > index 4f6330e..85e014d 100644
>> > --- a/xen/common/sched_credit.c
>> > +++ b/xen/common/sched_credit.c
>> > @@ -429,6 +429,24 @@ static inline void __runq_tickle(struct
>> > csched_vcpu *new)
>> >      idlers_empty = cpumask_empty(&idle_mask);
>> >
>> >      /*
>> > +     * Exclusive pinning is when a vcpu has hard-affinity with
>> > only one
>> > +     * cpu, and there is no other vcpu that has hard-affinity with
>> > that
>> > +     * same cpu. This is infrequent, but if it happens, is for
>> > achieving
>> > +     * the most possible determinism, and least possible overhead
>> > for
>> > +     * the vcpus in question.
>> > +     *
>> > +     * Try to identify the vast majority of these situations, and
>> > deal
>> > +     * with them quickly.
>> > +     */
>> > +    if ( unlikely(cpumask_cycle(cpu, new->vcpu->cpu_hard_affinity)
>> > == cpu &&
>>
>> Won't this check entail a full "loop" of the cpumask?  It's cheap
>> enough
>> if nr_cpu_ids is small; but don't we support (theoretically) 4096
>> logical cpus?
>>
>> It seems like having a vcpu flag that identifies a vcpu as being
>> pinned
>> would be a more efficient way to do this.  That way we could run this
>> check once whenever the hard affinity changed, rather than every time
>> we
>> want to think about where to run this vcpu.
>>
>> What do you think?
>>
> Right. We actually should get some help from the hardware (ffs &
> firends)... but I think you're right. Implementing this with a flag, as
>  you're suggesting, is most likely better, and easy enough.
>
> I'll go for that!

Cool.  BTW I checked the first 5 in.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel