Re: [Ext2-devel] Re: [RFC][PATCH 0/3] ext3 percpu counter fixes to suppport for ext3 unsigned long type free blocks counter

[Ravikiran G Thirumalai <kiran@scalex86.org>]

On Wed, Apr 12, 2006 at 02:28:35PM -0700, Mingming Cao wrote:
> On Tue, 2006-04-11 at 15:20 -0700, Ravikiran G Thirumalai wrote:
> > On Tue, Apr 11, 2006 at 12:01:13PM -0700, Mingming Cao wrote:
> > > On Tue, 2006-04-11 at 10:09 -0700, Christoph Lameter wrote:
> 
> 
> where the check for unsigned long overflow is only turned on 32 bit
> platforms.
> 
> > Or make the counter s64? so that it stays 64 bit on all arches? 
> > 
> 
> Well, don't we have the problem : 64 bit counter add/dec/update is not
> always atomic on all 32 bit platforms? There are risk that we will get
> bogus global value. 

Yes, but the global counter is modified with a lock in the SMP case, and the
local counters are modified by their respective cpus only,  Although there 
might be more subtle issues ..... 

> 
> > OR
> > why not change the global per-cpu counter type to unsigned long (as we
> > discussed earlier), so we don't need the extra "ul" flags and interfaces, 
> > and all arches get a standard unsigned long return type? 
> >  We could also 
> > do away with percpu_read_positive then no?  The applications for per-cpu 
> > counters is going to be upcounters always methinks...
> > 
> 
> yeah...I am not so happy with the extra "ul" checking flags either. But
> as you have mentioned before, the signed global counter type is there
> for some cases when the global counter becomes temporally negative
> ( although the counter in real life should always positive). What should
> we do if the global counter is a unsigned value, was initialized to 0,
> and now we add -5 to it(-5 is from one local counter, then we will get a
> bogus big value)?

I thought the solution to this was to have a global unsigned counter, and
signed local counter, and defer updates to the global if it is going to be a 
large value due to the case above. This way the global counter remains an up 
counter no?

Thanks,
Kiran