On 12/12/2012 11:53 PM, Oleg Nesterov wrote: > On 12/12, Srivatsa S. Bhat wrote: >> >> On 12/12/2012 10:54 PM, Oleg Nesterov wrote: >> >>> And when I look at get_online_cpus_atomic() again it uses rmb(). This >>> doesn't look correct, we need the full barrier between this_cpu_inc() >>> and writer_active(). >> >> Hmm.. >> >>> At the same time reader_nested_percpu() can be checked before mb(). >> >> I thought that since the increment and the check (reader_nested_percpu) >> act on the same memory location, they will naturally be run in the given >> order, without any need for barriers. Am I wrong? > > And this is what I meant, you do not need a barrier before > reader_nested_percpu(). >
Ah, ok! > But you need to ensure that WRITE(reader_percpu_refcnt) and > READ(writer_signal) > can't be reordered, so you need mb() in between. rmb() can serialize LOADs and > STOREs. > OK, got it. (I know you meant s/can/can't). I'm trying to see if we can somehow exploit the fact that the writer can potentially tolerate if a reader ignores his signal (to switch to rwlocks) for a while... and use this to get rid of barriers in the reader path (without using synchronize_sched() at the writer, of course). And perhaps also take advantage of the fact that the read_lock() acts as a one-way barrier.. I don't know, maybe its not possible after all.. :-/ Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
