Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB

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

On Tue, 2006-04-18 at 09:30 +0200, Arjan van de Ven wrote:
> On Tue, 2006-04-18 at 09:14 +0200, Laurent Vivier wrote:
> > Le lun 17/04/2006 à 23:32, Ravikiran G Thirumalai a écrit :
> > > On Mon, Apr 17, 2006 at 11:09:36PM +0200, Arjan van de Ven wrote:
> > > > On Mon, 2006-04-17 at 14:07 -0700, Ravikiran G Thirumalai wrote:
> > > > > 
> > > > > 
> > > > > I ran the same tests on a 16 core EM64T box very similar to the one
> > > > > you ran
> > > > > dbench on :). Dbench results on ext3 varies quite a bit.  I couldn't
> > > > > get 
> > > > > to a statistically significant conclusion  For eg,
> > > > 
> > > > 
> > > > dbench is not a good performance benchmark. At all. Don't use it for
> > > > that ;)
> > > 
> > > Agreed. (I did not mean to use it in the first place :).  I was just trying 
> > > to verify the benchmark results posted earlier)
> > > 
> > > Thanks,
> > > Kiran
> > 
> > What is the good performance benchmark to know if we should use atomic_t
> > instead of percpu_counter ?
> 
> you probably want something like postal/postmark instead or so (although
> that's not ideal either), at least that's reproducable
> 
postmark is a single threaded benchmark.

The ext3 filesystem free blocks counter is mostly being updated at block
allocation and free code. So, a test with many many threads doing block
allocation/deallocation simultaneously will stress the free blocks
counter accounting better than a single threaded fs benchmark. After
all, the main reason we choose to use percpu counter for the free blocks
counter at the first place, I believe, was to support parallel block
allocation. 

I would suggest run tiobench with many threads (>256), or even better,
run tiobench with many dd tests at the background.


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/