Re: [PATCH 1/2] ext3 percpu counter fixes to suppport for more than 2**31 ext3 free blocks counter

[Ravikiran G Thirumalai]

On Mon, Apr 24, 2006 at 10:48:32AM -0700, Mingming Cao wrote:
> On Fri, 2006-04-21 at 15:09 -0700, Andrew Morton wrote:
> > >
> > I think it would be saner to explicitly specify the size of the field. 
> > That means using s32 and s64 throughout this code.
> > 
> 
> Agree. Will use s64 in this code. As s32 has the same issue with what we
> have(unsigned long) on 32 bit machine today: it is not enough for ext3
> to support more than 2**31 free blocks, and also obviously not enough
> for 64 bit ext3 that Laurent is working on.

I think Andrew's suggestion was to change global counter to s64 and local
counter to s32.  That way we avoid allocating a 64 bit local counter on 64
bit systems when we could do with a 32 bit counter. (although there is no
real space savings with current alloc_percpu ;), but hopefully that will
change in the future)

> 
> I looked at the all users of percpu counter that are currently in
> mainline(2.6.17-rc1) and in mm tree(2.6.17-rc1-mm2), they are:
> 
> 1. ext2 free blocks/inodes/dirs 
> 	(int type, to be changed to unsinged long)
> 2. ext3 free blocks/inodes/dirs 
> 	(int type, changing to unsigned long or unsigned long long)
> 3. nr_files 
> 	(currently int type)
> 4. decnet_memory allocated 
> 	(was atomic_t type in mainline, changed to percpu counter type in mm)
> 5. tcp_memory allocated 
> 	(was atomic_t type, changed to percpu counter type in mm tree)
> 
> I could be wrong, but I think there will be no effect to change the size
> of the global counter from "long" to s64 for above percpu counter users,
> except gives the counter more room to grow. Kiran, what do you think?

Agree.  Since the counters were earlier int/atomic_t, s32 on local and s64 on
global should be OK.

> Did I miss any other users of the perpcu counters? 

No, AFAIK, these are the only users as of now.

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