[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 14:35:31 +0000
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 09 Dec 2010 06:36:56 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FNkke9ufmeDUGujYiy0v5EwXrj4X2ydxg20YFFJKmHE=; b=VZQQVrUwOh+Wue+CAgUBKcjBKqQsG/g8dCtvnTx/Bq7uXpT7kf3wrqKjCn9Ox7CBRC L2ubCNHPeoukvqOvEaYijDY8VT/N/lo3FoxkwIkcjd0tAz65XR8r91VphsShZXQ4qnj+ gs620X3X2erhsbuiv2X3ou7G8HyyKtpZo0gno=
- 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=rG16gKbrm10R1RDfyKwDWen+086iuAWnyX3Epiy51/JpBCykAgoKKxvWk6u441SyoU 0Tzl3ucm6QaZkNELls1C5/TCWviznj5LfRQSyabSd/FIoemeWneKS8vUeDfmlIClOu3f QuG4GxXgUXIkHkfdvlCDklbSJg3c/NRNvcIJQ=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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
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.
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:
>> 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
>> Xen-devel mailing list
> Xen-devel mailing list
Xen-devel mailing list