Re: x86: clean up smpboot.c's use of udelay+schedule

["Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>]

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