All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anshul Makkar <anshulmakkar@gmail.com>
Subject: Re: [PATCH 6/6] xen: sched: optimize exclusive pinning case (Credit1 & 2)
Date: Fri, 21 Jul 2017 21:55:52 +0200	[thread overview]
Message-ID: <1500666952.22958.7.camel@citrix.com> (raw)
In-Reply-To: <5962f895-18af-7180-0514-66b25c95d084@citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 2087 bytes --]

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!

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

  reply	other threads:[~2017-07-21 19:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 10:54 [PATCH 0/6] xen: sched: control structure memory layout optimizations Dario Faggioli
2017-06-23 10:54 ` [PATCH 1/6] xen: credit2: allocate runqueue data structure dynamically Dario Faggioli
2017-07-21 16:50   ` George Dunlap
2017-06-23 10:54 ` [PATCH 2/6] xen: credit2: make the cpu to runqueue map per-cpu Dario Faggioli
2017-07-21 16:56   ` George Dunlap
2017-06-23 10:55 ` [PATCH 3/6] xen: credit: rearrange members of control structures Dario Faggioli
2017-07-21 17:02   ` George Dunlap
2017-06-23 10:55 ` [PATCH 4/6] xen: credit2: " Dario Faggioli
2017-07-21 17:05   ` George Dunlap
2017-07-21 19:53     ` Dario Faggioli
2017-06-23 10:55 ` [PATCH 5/6] xen: RTDS: " Dario Faggioli
2017-07-21 17:06   ` George Dunlap
2017-07-21 17:51   ` Meng Xu
2017-07-21 19:51     ` Dario Faggioli
2017-06-23 10:55 ` [PATCH 6/6] xen: sched: optimize exclusive pinning case (Credit1 & 2) Dario Faggioli
2017-07-21 17:19   ` George Dunlap
2017-07-21 19:55     ` Dario Faggioli [this message]
2017-07-21 20:30       ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1500666952.22958.7.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=anshulmakkar@gmail.com \
    --cc=george.dunlap@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.