From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] SEDF: avoid gathering vCPU-s on pCPU0
Date: Fri, 01 Mar 2013 15:54:38 +0000 [thread overview]
Message-ID: <CD567FBE.5D211%keir@xen.org> (raw)
In-Reply-To: <5130D8D002000078000C26C6@nat28.tlf.novell.com>
On 01/03/2013 15:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> The introduction of vcpu_force_reschedule() in 14320:215b799fa181 was
> incompatible with the SEDF scheduler: Any vCPU using
> VCPUOP_stop_periodic_timer (e.g. any vCPU of half way modern PV Linux
> guests) ends up on pCPU0 after that call. Obviously, running all PV
> guests' (and namely Dom0's) vCPU-s on pCPU0 causes problems for those
> guests rather sooner than later.
>
> So the main thing that was clearly wrong (and bogus from the beginning)
> was the use of cpumask_first() in sedf_pick_cpu(). It is being replaced
> by a construct that prefers to put back the vCPU on the pCPU that it
> got launched on.
>
> However, there's one more glitch: When reducing the affinity of a vCPU
> temporarily, and then widening it again to a set that includes the pCPU
> that the vCPU was last running on, the generic scheduler code would not
> force a migration of that vCPU, and hence it would forever stay on the
> pCPU it last ran on. Since that can again create a load imbalance, the
> SEDF scheduler wants a migration to happen regardless of it being
> apparently unnecessary.
>
> Of course, an alternative to checking for SEDF explicitly in
> vcpu_set_affinity() would be to introduce a flags field in struct
> scheduler, and have SEDF set a "always-migrate-on-affinity-change"
> flag.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
> --- a/xen/common/sched_sedf.c
> +++ b/xen/common/sched_sedf.c
> @@ -397,7 +397,8 @@ static int sedf_pick_cpu(const struct sc
>
> online = cpupool_scheduler_cpumask(v->domain->cpupool);
> cpumask_and(&online_affinity, v->cpu_affinity, online);
> - return cpumask_first(&online_affinity);
> + return cpumask_cycle(v->vcpu_id % cpumask_weight(&online_affinity) - 1,
> + &online_affinity);
> }
>
> /*
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -605,7 +605,8 @@ int vcpu_set_affinity(struct vcpu *v, co
> vcpu_schedule_lock_irq(v);
>
> cpumask_copy(v->cpu_affinity, affinity);
> - if ( !cpumask_test_cpu(v->processor, v->cpu_affinity) )
> + if ( VCPU2OP(v)->sched_id == XEN_SCHEDULER_SEDF ||
> + !cpumask_test_cpu(v->processor, v->cpu_affinity) )
> set_bit(_VPF_migrating, &v->pause_flags);
>
> vcpu_schedule_unlock_irq(v);
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-03-01 15:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 15:35 [PATCH] SEDF: avoid gathering vCPU-s on pCPU0 Jan Beulich
2013-03-01 15:54 ` Keir Fraser [this message]
2013-03-02 3:44 ` Ian Campbell
2013-03-04 7:57 ` Jan Beulich
2013-03-05 15:54 ` [PATCH] SEDF: avoid gathering vCPU-s on pCPU0 [and 1 more messages] Ian Jackson
2013-03-05 16:11 ` Jan Beulich
2013-03-04 6:48 ` [PATCH] SEDF: avoid gathering vCPU-s on pCPU0 Juergen Gross
2013-03-04 7:59 ` Jan Beulich
2013-03-04 11:22 ` George Dunlap
2013-03-04 11:37 ` Jan Beulich
2013-03-04 12:11 ` George Dunlap
2013-03-04 12:23 ` Jan Beulich
2013-03-04 12:15 ` 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=CD567FBE.5D211%keir@xen.org \
--to=keir@xen.org \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xen.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.