This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] credit2's csched_init() registering of a CPU notifier

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] credit2's csched_init() registering of a CPU notifier
From: George Dunlap <george.dunlap@xxxxxxxxxx>
Date: Fri, 18 Mar 2011 15:30:05 +0000
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Mar 2011 08:26:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D835D4F02000078000373CA@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D8332E10200007800037367@xxxxxxxxxxxxxxxxxx> <4D835D4F02000078000373CA@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
csched_alloc_pdata() only calls init_pcpu() for cpu 0.

The problem here is that we have a dependency loop.  credit2 (at the
moment) wants to have one runqueue per socket.  However, at the time the
first csched_alloc_pdata() is called, the cpu topology information is
not yet available.  So for all cpus except cpu 0, we register a cpu
callback notifier, so that we can call init_pcpu() when the cpu is up
(at which point the topology information for that cpu is known).

Cpu 0 never gets a callback; so we special-case csched_alloc_pdata() to
call init_pcpu() for cpu 0, and to always assign cpu 0 to runqueue 0.

I know that this is almost certainly incredibly broken WRT cpu pools at
the moment.  I will fix it, but ATM it's just not a priority.


On Fri, 2011-03-18 at 12:25 +0000, Jan Beulich wrote:
> >>> On 18.03.11 at 10:24, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> > George,
> > 
> > as ->init() can be called more than once (for CPU pools) it seems
> > wrong to do any global initialization in ->init(). The question is
> > whether it's worth adding a ->global_init(), or whether instead
> > a callout from the notifier schedule.c sets up wouldn't be a
> > better mechanism (though that would require maintaining a list
> > of scheduler instances).
> Just moving this onto a global_init doesn't work (crashes), and
> looking at what the notifier handler does I wonder why it's
> needed at all - csched_alloc_pdata() also calls init_pcpu(), and
> that ought to be the canonical way. Plus there's also this
> somewhat frightening comment "Hope this is safe from cpupools
> switching things around. :-)" in csched_cpu_starting().
> Minimally I think there needs to be a check that *ops really is
> credit2's.
> Jan

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>