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

[Mingming Cao <cmm@us.ibm.com>]

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:
> > > On Mon, 10 Apr 2006, Mingming Cao wrote:
> > > 
> > > > Here are the proposed patches to allow the ext3 free block accounting
> > > > works with more than 8TB storage.
> > > 
> > > Umm.. This is an issue on 32 bit platforms only. 64bit platforms x86_64, 
> > > ia64 etc do not need this. Would you make it arch specific?
> > 
> > Yes, make sense. I will update my patch soon. Thanks.
> 
I was thinking something like this:

+void percpu_counter_mod_ul(struct percpu_counter *fbc, long amount)
+{
+       preempt_disable();
+       __percpu_counter_mod(fbc, amount, BITS_PER_LONG<=32);
+       preempt_enable();
+}
+EXPORT_SYMBOL(percpu_counter_mod_ul);


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. 

> 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)?

ext3 free blocks counter is always initialized to a big positive value
so I doubt above concern is a real issue for ext3. Perhaps you thought
this through that it's okay to change the global counter to unsigned
long for other applications of PCP counters?

Thanks,
Mingming

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/