[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] Rendezvous selected cpus
>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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |