[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Rendezvous selected cpus
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |