From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mingming Cao Subject: Re: [RFC][PATCH 1/3] per cpu counter fixes for unsigned long type counter overflow Date: Tue, 11 Apr 2006 10:23:41 -0700 Message-ID: <1144776221.3986.0.camel@dyn9047017067.beaverton.ibm.com> References: <1144691947.3964.54.camel@dyn9047017067.beaverton.ibm.com> <20060410151817.27766565.akpm@osdl.org> <1144717779.3964.93.camel@dyn9047017067.beaverton.ibm.com> <20060411075440.GQ17364@schatzie.adilger.int> Reply-To: cmm@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Andrew Morton , kiran@scalex86.org, Laurent.Vivier@bull.net, linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:48364 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S1751029AbWDKRXp (ORCPT ); Tue, 11 Apr 2006 13:23:45 -0400 To: Andreas Dilger In-Reply-To: <20060411075440.GQ17364@schatzie.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2006-04-11 at 01:54 -0600, Andreas Dilger wrote: > On Apr 10, 2006 18:09 -0700, Mingming Cao wrote: > > +static void __percpu_counter_mod(struct percpu_counter *fbc, long amount, > > + int ul_overflow_check) > > { > > + * Before updating the global counter, if we detect the > > + * updated new value will cause overflow, then we should not > > + * do the update from this local counter at this moment. (i.e. > > + * the local counter will not be cleared right now). The update > > + * will be deferred at some point until either other local > > + * counter updated the global counter first, or the local > > + * counter's value will not cause global counter overflow. > > Wouldn't it be better to update the counter by the maximum amount possible > to avoid overflow/underflow? > Yep. Thanks for pointing this out.:) Mingming > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. >