lkml.org 
[lkml]   [2012]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86: clean up smpboot.c's use of udelay+schedule
On 02/02/2012 06:03 AM, Paul E. McKenney wrote:

> On Tue, Jan 31, 2012 at 02:01:56PM +0100, Peter Zijlstra wrote:
>> On Tue, 2012-01-31 at 13:53 +0100, Ingo Molnar wrote:
>>> Wanna give a short TODO list to anyone wanting to work on that?
>>
>> I paged out most details again, but it goes something like:
>>
>> - read and understand the current generic code
>>
>> - and all architecture code, at which point you'll probably boggle
>> at all the similarities that are all subtly different (there's
>> about 3 actually different ways in the arch code).
>>
>> - pick one, preferably one that keeps additional state and doesn't
>> fully rely on the online bits and pull it into generic code and
>> provide a small vector of arch specific functions.
>>
>> - convert all archs over.
>>
>>
>> Also related:
>>
>> - figure out why cpu_down needs kstopmachine, I'm not sure it does..
>> we should be able to tear down a cpu using synchronize_sched() and a
>> single stop_one_cpu(). (someday when there's time I might actually
>> try to implement this).
>
> Currently, a number of the CPU_DYING notifiers assume that they are
> running in stop-machine context, including those of RCU.
>
> However, this is not an inherent property of RCU -- DYNIX/ptx's
> CPU-offline process did not stop the whole machine, after all, and RCU
> (we called it rclock, but whatever) was happy with this arrangement.
> In fact, if the outgoing CPU could be made to stop in that context
> instead of returning to the scheduler and the idle loop, it would make
> my life a bit easier.
>
> My question is why aren't the notifiers executed in the opposite
> order going down and coming up, with the coming-up order matching the
> boot order? Also, why can't the CPU's exit from this world be driven
> out of the idle loop? That way, the CPU wouldn't mark itself offline
> (thus in theory to be ignored by CPU), and then immediately dive into
> the scheduler and who knows what all else, using RCU all the time. ;-)
>
> (RCU handles this by keeping a separate set of books for online CPUs.
> It considers a CPU online at CPU_UP_PREPARE time, and doesn't consider
> it offline until CPU_DEAD time. To handle the grace periods between,
> force_quiescent_state() allows the grace period to run a few jiffies
> before checking cpu_online_map, which allows a given CPU to safely use
> RCU for at least one jiffy before marking itself online and for at least
> one jiffy after marking itself offline.)
>
> Yet another question is about races between CPU-hotplug events and
> registering/unregistering cpu notifiers. I don't believe that the
> current code does what you would like in all cases.


I beg to differ here. There is no race between CPU-hotplug and registering
or unregistering of cpu notifiers. The pair cpu_maps_update_begin() and
cpu_maps_update_done() is supposed to take care of that right?


> The only way
> I can imagine it really working would be to use generation numbers,
> so that once a CPU-hotplug event started, it would invoke only those
> notifiers marked with the generation that was in effect when the
> event started, or with some earlier generation.
>


Regards,
Srivatsa S. Bhat
IBM Linux Technology Center



\
 
 \ /
  Last update: 2012-02-02 09:07    [W:1.122 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site