[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Keir Fraser <keir@xxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Thu, 9 Dec 2010 17:33:54 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 09 Dec 2010 09:35:02 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D27sxTrv4v/g6t5ubcuQvaj70j6u3b1evKpM1yL0ZNpuZDUDnYl2KqbKCVPUaelJO9 KTydljikVcR4n3AeVfPAsgu2LCbtujmwMn8R7FIkqVFu+qMH4ZfDEdqKb9C6XRslcc7s zNfu0UnjIJ+t9AA0i/bE93ssx08YonGkWdSyw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

That works great, thanks!
 -George

On Thu, Dec 9, 2010 at 4:20 PM, Keir Fraser <keir@xxxxxxx> wrote:
> 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
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.