From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [RFC][PATCH] Scheduler interface changes for credit2
Date: Mon, 22 Feb 2010 15:22:03 +0000 [thread overview]
Message-ID: <de76405a1002220722q30d55ed0t9f26f33c95d10933@mail.gmail.com> (raw)
In-Reply-To: <de76405a1002150920g5a6fd098xcea9a28d491e3b54@mail.gmail.com>
Keir, any thoughts? Does this seem like a reasonable approach?
Thanks,
-George
On Mon, Feb 15, 2010 at 5:20 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> The two attached patches change the scheduler interface to allow
> credit2 to have several cpus share the same runqueue. The patches
> should have almost no impact on the current schedulers. The patches
> and their reasonings are below. I've also attached the patches for
> the prototype credit2 scheduler, for reference.
>
> * Add a context swich callback (sched-context_switch-callback.diff)
>
> Add a callback to tell a scheduler that a vcpu has been completely
> context-switched off a cpu.
>
> When sharing a runqueue, we can't put a scheduled-out vcpu back on the
> runqueue until it's been completely de-scheduled, because it may be
> grabbed by another processor before it's ready. This callback allows
> a scheduler to detect when a vcpu on its way out is completely off the
> processor, so that it can put the vcpu on the runqueue.
>
> * Allow sharing of locks between cpus (sched-spin_lock-pointers.diff)
>
> Have per-cpu pointers, initialized to per-cpu locks, which the
> scheduler may change during its init to reconfigure locking
> granularity.
>
> There are a number of race conditions having to do with updating of
> v->is_running and v->processor, all having to do with the fact that
> vcpus may change cpus without an explicit migrate. Furthermore, the
> scheduler needs runqueues to be covered by a lock as well. The
> cleanest way to solve all of these is to have the scheduler lock and
> the runqueue lock coincide.
>
> * Add a "scheduler" trace class (trace-sched-class.diff)
> Uses defined on a per-scheduler basis
>
> I've been running parallel kernel compiles on a 16-way box (2x4x2) for
> several hours now without deadlocks or BUG()s. As far as I'm
> concerned, with these changes, credit2 is now ready to be checked in,
> as long as it's not set to the default scheduler.
>
> All of the above:
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
next prev parent reply other threads:[~2010-02-22 15:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-15 17:20 [RFC][PATCH] Scheduler interface changes for credit2 George Dunlap
2010-02-22 15:22 ` George Dunlap [this message]
2010-02-22 15:38 ` Keir Fraser
2010-02-22 16:16 ` George Dunlap
2010-02-22 17:32 ` Keir Fraser
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=de76405a1002220722q30d55ed0t9f26f33c95d10933@mail.gmail.com \
--to=george.dunlap@eu.citrix.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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).