Le lun 10/04/2006 à 21:06, Mingming Cao a écrit : > On Mon, 2006-04-10 at 09:57 -0700, Mingming Cao wrote: > > On Mon, 2006-04-10 at 11:11 +0200, Laurent Vivier wrote: [...] > Hi Laurent, > > Just looked at your patch, shouldn't we use atomic_long_add() instead of > atomic_long_set() to replace percpu_counter_mod()? Yes, thank you. > > 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. I made some tests with iozone on 2 CPU hyperthreaded computer (= 4 CPUs, Bull Express 5800 120 Lh), and it seems atomic_t is faster than "percpu_counter". I'll try to make some tests on IBM x440 (8 CPUs, 16 if hyperthreaded) with iozone and sysbench. Moreover, I think percpu_counter uses a lot of memory... > 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:( Anyway, wa can't have a 64bit addressing space on a 32bit machine, so I think, for the moment, it's not a problem. Regards, Laurent -- Laurent Vivier Bull, Architect of an Open World (TM) http://www.bullopensource.org/ext4
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
- Follow-Ups:
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Ravikiran G Thirumalai <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- References:
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Laurent Vivier <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Mingming Cao <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Mingming Cao <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- Prev by Date: Re: [PATCH] cleanup after deinlining patch 1/2
- Next by Date: Re: [PATCH] cleanup after deinlining patch 1/2
- Previous by thread: Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- Next by thread: Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- Index(es):