Messages in this thread | | | Date | Tue, 24 Sep 2013 22:35:12 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] hotplug: Optimize {get,put}_online_cpus() |
| |
On Tue, Sep 24, 2013 at 08:00:05PM +0200, Oleg Nesterov wrote: > On 09/24, Paul E. McKenney wrote: > > > > On Tue, Sep 24, 2013 at 07:06:31PM +0200, Oleg Nesterov wrote: > > > > > > If gcc can actually do something wrong, then I suspect this barrier() > > > should be unconditional. > > > > If you are saying that there should be a barrier() on all return paths > > from get_online_cpus(), I agree. > > Paul, Peter, could you provide any (even completely artificial) example > to explain me why do we need this barrier() ? I am puzzled. And > preempt_enable() already has barrier... > > get_online_cpus(); > do_something(); > > Yes, we need to ensure gcc doesn't reorder this code so that > do_something() comes before get_online_cpus(). But it can't? At least > it should check current->cpuhp_ref != 0 first? And if it is non-zero > we do not really care, we are already in the critical section and > this ->cpuhp_ref has only meaning in put_online_cpus(). > > Confused...
So the reason I put it in was because of the inline; it could possibly make it do:
test 0, current->cpuhp_ref je label1: inc current->cpuhp_ref
label2: do_something();
label1: inc %gs:__preempt_count test 0, __cpuhp_writer jne label3 inc %gs:__cpuhp_refcount label5 dec %gs:__preempt_count je label4 jmp label2 label3: call __get_online_cpus(); jmp label5 label4: call ____preempt_schedule(); jmp label2
In which case the recursive fast path doesn't have a barrier() between taking the ref and starting do_something().
I wanted to make absolutely sure nothing of do_something leaked before the label2 thing. The other labels all have barrier() from the preempt_count ops.
| |