Thanks!
Concerning cpu online/offline development, I have a small question here.
Since cpu_online_map is very important, code in different subsystems may use it
extensively. If such code is not designed with cpu online/offline in mind, it
may introduce race conditions, just like the one fixed in cpu calibration
rendezvous.
Currently, we solve it in a find-and-fix manner. Do you have any idea that can
solve the problem in a cleaner way?
Thanks in advance.
Shan Haitao
-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: 2008年9月11日 19:13
To: Shan, Haitao; Haitao Shan
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
It looks much better. I'll read through, maybe tweak, and most likely then
check it in.
Thanks,
Keir
On 11/9/08 09:02, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
> Hi, Keir,
>
> Attached is the updated patch using the methods as you described in
> another mail.
> What do you think of the one?
>
> Signed-off-by: Shan Haitao <haitao.shan@xxxxxxxxx>
>
> Best Regards
> Haitao Shan
>
> Haitao Shan wrote:
>> Agree. Placing migration in stop_machine context will definitely make
>> our jobs easier. I will start making a new patch tomorrow. :)
>> I place the migraton code outside the stop_machine_run context, partly
>> because I am not quite sure how long it will take to migrate all the
>> vcpus away. If it takes too much time, all useful works are blocked
>> since all cpus are in the stop_machine context. Of course, I borrowed
>> the ideas from kernel, which also let me made the desicion.
>>
>> 2008/9/10 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
>>> I feel this is more complicated than it needs to be.
>>>
>>> How about clearing VCPUs from the offlined CPU's runqueue from the
>>> very end of __cpu_disable()? At that point all other CPUs are safely
>>> in softirq context with IRQs disabled, and we are running on the
>>> correct CPU (being offlined). We could have a hook into the
>>> scheduler subsystem at that point to break affinities, assign to
>>> different runqueues, etc. We would just need to be careful not to
>>> try an IPI. :-) This approach would not need a cpu_schedule_map
>>> (which is really increasing code fragility imo, by creating possible
>>> extra confusion about which cpumask is the wright one to use in a
>>> given situation).
>>>
>>> My feeling, unless I've missed something, is that this would make
>>> the patch quite a bit smaller and with a smaller spread of code
>>> changes.
>>>
>>> -- Keir
>>>
>>> On 9/9/08 09:59, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
>>>
>>>> This patch implements cpu offline feature.
>>>>
>>>> Best Regards
>>>> Haitao Shan
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
|
Home