From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mingming Cao Subject: Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB Date: Tue, 18 Apr 2006 14:01:53 -0700 Message-ID: <1145394113.3771.11.camel@dyn9047017067.beaverton.ibm.com> References: <1143530126.11560.6.camel@openx2.frec.bull.fr> <1143568905.3935.13.camel@dyn9047017067.beaverton.ibm.com> <1143623605.5046.11.camel@openx2.frec.bull.fr> <1143682730.4045.145.camel@dyn9047017067.beaverton.ibm.com> <20060329175446.67149f32.akpm@osdl.org> <1144660270.5816.3.camel@openx2.frec.bull.fr> <20060410012431.716d1000.akpm@osdl.org> <1144941999.2914.1.camel@openx2.frec.bull.fr> <20060417210746.GB3945@localhost.localdomain> <1145308176.2847.90.camel@laptopd505.fenrus.org> <20060417213201.GC3945@localhost.localdomain> <1145344481.17767.1.camel@openx2.frec.bull.fr> <1145345407.2976.13.camel@laptopd505.fenrus.org> Reply-To: cmm@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Laurent Vivier , Ravikiran G Thirumalai , Andrew Morton , Takashi Sato , linux-kernel@vger.kernel.org, ext2-devel , linux-fsdevel@vger.kernel.org Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:5326 "EHLO e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S932271AbWDRVCD (ORCPT ); Tue, 18 Apr 2006 17:02:03 -0400 To: Arjan van de Ven In-Reply-To: <1145345407.2976.13.camel@laptopd505.fenrus.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 =C3=A0 23:32, Ravikiran G Thirumalai a =C3=A9crit= : > > > 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= : > > > > >=20 > > > > >=20 > > > > > I ran the same tests on a 16 core EM64T box very similar to t= he one > > > > > you ran > > > > > dbench on :). Dbench results on ext3 varies quite a bit. I c= ouldn't > > > > > get=20 > > > > > to a statistically significant conclusion For eg, > > > >=20 > > > >=20 > > > > dbench is not a good performance benchmark. At all. Don't use i= t for > > > > that ;) > > >=20 > > > Agreed. (I did not mean to use it in the first place :). I was j= ust trying=20 > > > to verify the benchmark results posted earlier) > > >=20 > > > Thanks, > > > Kiran > >=20 > > What is the good performance benchmark to know if we should use ato= mic_t > > instead of percpu_counter ? >=20 > you probably want something like postal/postmark instead or so (altho= ugh > that's not ideal either), at least that's reproducable >=20 postmark is a single threaded benchmark. The ext3 filesystem free blocks counter is mostly being updated at bloc= k 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 block= s counter at the first place, I believe, was to support parallel block allocation.=20 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-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html