From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC][PATCH] Scheduler interface changes for credit2 Date: Mon, 22 Feb 2010 15:38:59 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org They're all fine, even probably sched-context_switch-callback.diff, which I suppose is your new alternative to having vcpus-which-arent-yet-schedulable left on the shared runqueue? I suppose, although I reckon it could still be done another way and using the vcpu_migrate logic, that this is a smaller and neater way to do it really. All this are apply-able after 4.0. -- Keir On 22/02/2010 15:22, "George Dunlap" wrote: > Keir, any thoughts? Does this seem like a reasonable approach? >=20 > Thanks, > -George >=20 > On Mon, Feb 15, 2010 at 5:20 PM, George Dunlap > wrote: >> The two attached patches change the scheduler interface to allow >> credit2 to have several cpus share the same runqueue. =A0The patches >> should have almost no impact on the current schedulers. =A0The patches >> and their reasonings are below. =A0I've also attached the patches for >> the prototype credit2 scheduler, for reference. >>=20 >> * Add a context swich callback (sched-context_switch-callback.diff) >>=20 >> Add a callback to tell a scheduler that a vcpu has been completely >> context-switched off a cpu. >>=20 >> 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. =A0This 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. >>=20 >> * Allow sharing of locks between cpus (sched-spin_lock-pointers.diff) >>=20 >> Have per-cpu pointers, initialized to per-cpu locks, which the >> scheduler may change during its init to reconfigure locking >> granularity. >>=20 >> 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. =A0Furthermore, the >> scheduler needs runqueues to be covered by a lock as well. =A0The >> cleanest way to solve all of these is to have the scheduler lock and >> the runqueue lock coincide. >>=20 >> * Add a "scheduler" trace class (trace-sched-class.diff) >> Uses defined on a per-scheduler basis >>=20 >> I've been running parallel kernel compiles on a 16-way box (2x4x2) for >> several hours now without deadlocks or BUG()s. =A0As 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. >>=20 >> All of the above: >> Signed-off-by: George Dunlap >>=20