On Mon, 2006-04-10 at 09:57 -0700, Mingming Cao wrote:
> On Mon, 2006-04-10 at 11:11 +0200, Laurent Vivier wrote:
> > Le jeu 30/03/2006 à 03:54, Andrew Morton a écrit :
> > > Mingming Cao <[email protected]> wrote:
> > > >
> > > > The things need to be done to complete this work is the issue with
> > > > current percpu counter, which could not handle u32 type count well.
> > >
> > > I'm surprised there's much of a problem here. It is a 32-bit value, so it
> > > should mainly be a matter of treating the return value from
> > > percpu_counter_read() as unsigned long.
> > >
> > > However a stickier problem is when dealing with a filesystem which has,
> > > say, 0xffff_ff00 blocks. Because percpu counters are approximate, and a
> > > counter which really has a value of 0xffff_feee might return 0x00000123.
> > > What do we do then?
> > >
> > > Of course the simple option is to nuke the percpu counters in ext3 and use
> > > atomic_long_t (which is signed, so appropriate treat-it-as-unsigned code
> > > would be needed). I doubt if the percpu counters in ext3 are gaining us
> > > much.
> >
> > I tried to make something in this way.
> > Does the attached patch look like the thing you though about ?
> >
>
Hi Laurent,
Just looked at your patch, shouldn't we use atomic_long_add() instead of
atomic_long_set() to replace percpu_counter_mod()?
> I tried the other way -- I am trying to keep the percpu counter in use
> in ext2/3 as much as possible. I proposed a fix for percpu counter to
> deal with the possible "overflow" (i.e, a counter really has a value of
> 0xfff_feee and after updating one local counter it truens 0x00000123).
> Will send the proposed patch out for review and comments soon.
>
Anyway, I am not against the atomic way. Just thought there must be
reasons where we use percpu counters -- the cache pollution on smp
machine is certainly a concern if we use atomic instead, so I tried to
fix percpu counter first.
I think my fix for percpu counter should work, and the changes doesn't
affect other users of current percpu counters(vfs and network). Kiran,
Andrew, please review it (posted in another seperate thread). If not,
then I guess we have to use atomic counter -- this is performance vs
capacity kind of trade off.
But both methods don't support 64 bit ext3 block number on 32 bit
machine...I am not happy with this but can't think of a way to fix this
without taking a global lock:(
Mingming
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Ext2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ext2-devel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
