Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen

["Haitao Shan" <maillists.shan@xxxxxxxxx>]

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