WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] CPU and scheduler init, Part 2

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] CPU and scheduler init, Part 2
From: Keir Fraser <keir@xxxxxxx>
Date: Thu, 09 Dec 2010 14:41:01 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Dec 2010 06:42:13 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=XVz9W+yB9eEa+8gu8RrFTP4s+CqLxT6cCkteF0oA3tU=; b=fHW5BST1gxPM3ac9rjjgfRTcWlZKzYCrSIkcDzjqf088fWBf0Qyc3jVFki1JGZbH3m uFTByDeXPhseco2Y80MWSVkGe31tWU/xQxrLyDdh4MKL5IabYZ3rVo8eMrlDwfz+7HVA U6Hgx2F4XDVom9QGT743Z1+JA11PA8MlK86mc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=FF0SKZoPVG61HYUaLHmIGlcqS4/dk/NsDAJz2QxPmoydLXts89tUHr5gCroxfslyd9 BGL+qXCwpvkxGIsibDBtWVXibO3VskujBoNu1h8qIxPOsFZYwqPw5CqYammJSq2AEVhs oit9/Bkx1cYb+cIlG3tx3yg/q0IOsoOmUn8E8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimYpgKfGPmqx2oO0RRH6fazWkXP3SS4V9m68x6w@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcuXrxlQaAlSc38hQU2vQh+AreLBuA==
Thread-topic: [Xen-devel] CPU and scheduler init, Part 2
User-agent: Microsoft-Entourage/12.27.0.100910
On 09/12/2010 14:35, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:

> That could work, if you want.  ATM I don't allocate anything; if I
> need to in the future, I should be able to do it allocation in
> alloc_pdata().
> 
> I don't strictly need it to run on the processor that's coming up; I just
> need:
> * The function to happen after the cpu ID stuff, so that (for example)
> cpu_to_socket() returns a reasonable value
> * The function to finish before the cpu tries to run the scheduler
> 
> But if you'd rather add CPU_STARTING than an interlock for CPU_ONLINE
> for technical reasons, that's fine.

CPU_ONLINE means that cpu is already in cpu_online_map. I doubt you'd want
to delay this scheduler stuff until then -- at that point other cpus can see
you and poke your runqueue. So I think a new notifier type is required, and
we may as well stick with Linux-ish semantics with CPU_STARTING.

 -- Keir

> Thanks,
>  -George
> 
> 
> On Thu, Dec 9, 2010 at 2:16 PM, Keir Fraser <keir@xxxxxxx> wrote:
>> On 09/12/2010 12:49, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:
>> 
>>> Keir,
>>> 
>>> I made a cpu status notifier for sched_credit2() to actually read an
>>> arrange the runqueue information, and found the next niggle: the
>>> callbacks are not guaranteed to finish before the cpu tried to go
>>> through the scheduler.  The callback notifiers are handled on the cpu
>>> that issues the boot command (i.e., cpu 0 during boot), and there's no
>>> interlock to prevent the booted cpu from continuing until the
>>> notifiers have completed execution.
>>> 
>>> Making a simple interlock (similar to the one in __cpu_up()) allows
>>> the system to boot properly.  Another possibility would be to run the
>>> notifiers on the freshly booted cpu before calling into the scheduler,
>>> rather than on the cpu that issued the cpu boot sequence.
>> 
>> I could bring Linux's CPU_STARTING notifier over into Xen. Runs in context
>> of new CPU before it is fully online (e.g., before interrupts are enabled).
>> So you couldn't do any allocations there, or anything else that can fail.
>> This might require some juggling to pre-allocate memory (e.g., for
>> possibly-required new runqueue) on CPU_UP_PREPARE/alloc_pdata, and
>> potentially free that memory if unused on CPU_ONLINE. Or not, if actually
>> you require no dynamic memory allocation.
>> 
>> This might be the best solution overall I think? I can knock up a patch for
>> CPU_STARTING if that sounds good.
>> 
>>  -- Keir
>> 
>>> Thoughts?
>>> 
>>>  -George
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel