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 Thu, Apr 13, 2006 at 03:25:39PM -0700, Mingming Cao wrote:
> On Thu, 2006-04-13 at 12:02 -0700, Ravikiran G Thirumalai wrote:
> > ...
> > 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 ..... 
> > 
> Hmm, I was worried about the read to the 64 bit global counter, there is
> no lock to protect it from getting an half updated 64 bit counter. But I
> think the window is probably small, and with what Andreas suggested
> (keep the local per cpu counter as 32 bit value), we would avoid this
> non-atomic math in most cases.
> 
> Well,anyway this counter is just an approximate value, and currently
> (with 32 bit global counter) we could still read an old global counter
> value while it's being updated since no lock is required while read it.

Yup, and percpu_counter_exceeds should take care of the race in global
counter reads where it matters.


> > 
> > 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?
> > 
> 
> I think that will work, and we could get rid of the cheating
> percpu_counter_read_positive() totally;)
> 
> So I think we could combine these two together: make the global counter
> an unsigned 64 bit (u64) and keep the per cpu counter still signed 32
> bit type, and also, defer updates the global counter to the global if
> the end result is larger that before. This way we could have remove the
> need for percpu_counter_read_positive(), and also allow the counter
> being used for 64 bit accounting on 32 bit arch.
> 
> Comments?

Sounds OK to me.

Thanks,
Kiran