On Tue, 2011-11-22 at 21:41 +0800, Wu Fengguang wrote: > On Tue, Nov 22, 2011 at 09:07:50PM +0800, Wu Fengguang wrote: > > On Tue, Nov 22, 2011 at 08:57:42PM +0800, Peter Zijlstra wrote: > > > On Tue, 2011-11-22 at 13:21 +0100, Jan Kara wrote: > > > > > + __get_cpu_var(bdp_ratelimits)++; > > > > I think you need preempt_disable() and preempt_enable() pair around > > > > __get_cpu_var(). Otherwise a process could get rescheduled in the middle of > > > > read-modify-write cycle... > > > > > > there's of course the this_cpu_inc(bdp_ratelimits); thing. > > > > > > On x86 that'll turn into a single insn, on others it will add the > > > required preempt_disable/enable bits. > > > > It's good to know that. But what if we don't really care which CPU > > data it's increasing, and can accept losing some increases due to the > > resulted race condition? > > I just added a comment for it, hope it helps :) > > /* > * This is racy, however bdp_ratelimits merely serves as a > * gross safeguard. We don't really care the exact CPU it's > * charging to and the resulted inaccuracy is acceptable. > */ > __get_cpu_var(bdp_ratelimits)++; Thing is, I'm not sure how much update you can effectively wreck by interleaving the RmW cycles of two CPUs like this. Simply loosing a few increments would be fine, but what are the practical implications of actually relying on this behaviour and how do various architectures cope. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
