From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>, xen-devel@lists.xenproject.org
Cc: Anshul Makkar <anshul.makkar@citrix.com>,
Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 2/3] xen: Have schedulers revise initial placement
Date: Tue, 26 Jul 2016 11:30:13 +0200 [thread overview]
Message-ID: <1469525413.32102.12.camel@citrix.com> (raw)
In-Reply-To: <1469460493-18842-2-git-send-email-george.dunlap@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 2594 bytes --]
On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote:
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic can end
> up picking a pcpu that's not in the online mask. When this is passed
> to a scheduler such which assumes that the initial assignment is
> valid, it causes a null pointer dereference looking up the runqueue.
>
Looking more at Credit2 code, I think there are a couple of missing
checks that a cpu that is about to be used for something, is actually
in online.
However, that is orthogonal with this patch and...
> Furthermore, this initial placement doesn't take into account hard or
> soft affinity, or any scheduler-specific knowledge (such as historic
> runqueue load, as in credit2).
>
... using pick_cpu() here is, IMO, a really really really good idea, so
I think this patch should go in (and I'll work on and, if I am right,
add the missing checks).
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> v2:
> - Actually grab lock before calling vcpu_schedule_lock() to avoid
> tripping over a new ASSERT
>
Ah, yes... sorry! :-P
Just one thing:
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2055,12 +2055,21 @@ csched2_vcpu_insert(const struct scheduler
> *ops, struct vcpu *vc)
> ASSERT(!is_idle_vcpu(vc));
> ASSERT(list_empty(&svc->runq_elem));
>
> - /* Add vcpu to runqueue of initial processor */
> + /* csched2_cpu_pick() expects the pcpu lock to be held */
> lock = vcpu_schedule_lock_irq(vc);
>
> + vc->processor = csched2_cpu_pick(ops, vc);
> +
> + spin_unlock_irq(lock);
> +
> + lock = vcpu_schedule_lock_irq(vc);
> +
> + /* Add vcpu to runqueue of initial processor */
> runq_assign(ops, vc);
>
> vcpu_schedule_unlock_irq(lock, vc);
> +
> + local_irq_enable();
>
This local_irq_enable() is not necessary any longer, is it?
With that off (and I'd be fine if you want to do that while
committing):
Reviwed-by: Dario Faggioli <dario.faggioli@citrix.com>
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
next prev parent reply other threads:[~2016-07-26 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 15:28 [PATCH v2 1/3] xen: Some code motion to avoid having to do forward-declaration George Dunlap
2016-07-25 15:28 ` [PATCH v2 2/3] xen: Have schedulers revise initial placement George Dunlap
2016-07-25 17:34 ` Meng Xu
2016-07-26 9:30 ` Dario Faggioli [this message]
2016-07-26 9:35 ` George Dunlap
2016-07-25 15:28 ` [PATCH v2 3/3] xen: Remove buggy initial placement algorithm George Dunlap
2016-07-26 9:14 ` Dario Faggioli
2016-07-26 9:22 ` Andrew Cooper
2016-07-26 9:32 ` [PATCH v2 1/3] xen: Some code motion to avoid having to do forward-declaration Dario Faggioli
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=1469525413.32102.12.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=anshul.makkar@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=mengxu@cis.upenn.edu \
--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.