[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 4 Feb 2008 15:33:22 +0800
  • Delivery-date: Sun, 03 Feb 2008 23:46:35 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Achlcy9d/rIcXbNERJmDq57BBZNC3QBGTqlDAA+IkJAADVOV/AAABKIQ
  • Thread-topic: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.