RE: [Xen-devel] [PATCH] Rendezvous selected cpus

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2008年2月4日 15:31
>
>On 4/2/08 02:02, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> All above just made me distraught to follow Linux semantics, and
>> further thought leads me to why not let cpu_i to conduct stop process
>> directly, and then let concerned cpus to call (*fn) by adding a new
>> action as ***_INVOKE. By this way, cpu_i doesn't need to be cut
>> off from current flow, and once stop_machine returns, all necessary
>> works to be handled in a stopped environment are fulfilled.
>
>Yes, I saw that, but it doesn't require a modified interface. 
>The semantics
>of the call are still:
> 1. Synchronize/rendezvous all CPUs (the caller is assumed 
>already to be at
>a safe point and just needs to disable IRQs at the right time).
> 2. Run the (*fn) on one designated CPU (via your new bit of 
>mechanism).
> 3. All done.
>
>This fits fine within the stop_machine_run(fn, data, cpu) 
>interface, albeit
>that the underlying implementation is somewhat different (and 
>you already
>have that pretty much correct!).
>
>Really all you need to do is put your implementation in a 
>different file, do
>some simple renaming of stuff, push some of your caller code 
>(the bits that
>create the cpumasks) into your stop_machine_run() 
>implementation and give
>stop_machine_run() the simple Linux interface.
>
> -- Keir
> 

Well, understand this time. Reshuffle the code now. :-)

Thanks,
Kevin

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