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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
