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 16:20:24 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Dec 2010 08:21:41 -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=wUc9zLUtVE8FhJJy2IKlBf95zhjlHG9vmWylT2E1sqE=; b=IbdVVgYDhQpgPcj9le7YXgvQ6vCf0eSz7yXh6qeRbgSz1HK406yy8XbFRnlMiTu+CA NumupeGXqme+VUeK1DVzWeaWErY+wzIMYoFJVAQGBQRAvd8c1TQPpjl3fQWOZ4uCZw9O 12ReZRIw+dW8c+G1Xo1LNKa/i0FeOF2hUP0ww=
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=HLu0sCemddT92v3jJ2hwlko4bNv3RZv2WKe6sHCV4v5TcYUhGCZO8bfAD00JCK7JSj YddtJNp0EDtaa90BrzzB3kgpw/ef4ErzsBvUaVgYAiaJeFiDC4FZu+pjq7+8nalChkqC D1EXHnoYNLYDmLD9ekOSGIfobj8/aI6DVLhs8=
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: AcuXvPuKmbFdOiUTc0yNqTHeIJ0/Cg==
Thread-topic: [Xen-devel] CPU and scheduler init, Part 2
User-agent: Microsoft-Entourage/12.27.0.100910
I implemented CPU_STARTING as xen-unstable:22474.

 -- Keir

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.
> 
> 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