From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH 3/5] writeback: fix dirtied pages accounting on sub-page writes Date: Tue, 22 Nov 2011 21:41:55 +0800 Message-ID: <20111122134155.GA23599@localhost> References: <20111121130342.211953629@intel.com> <20111121131215.905222115@intel.com> <20111122001127.GG4017@quack.suse.cz> <20111122092110.GB12864@localhost> <20111122122157.GB8058@quack.suse.cz> <1321966662.5148.35.camel@twins> <20111122130750.GA19929@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , "linux-fsdevel@vger.kernel.org" , Christoph Hellwig , Andrew Morton , LKML To: Peter Zijlstra Return-path: Content-Disposition: inline In-Reply-To: <20111122130750.GA19929@localhost> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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)++; Thanks, Fengguang