xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).