Le mar 18/04/2006 à 09:30, Arjan van de Ven a écrit : > 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 I made some tests with kernbench too: ***** With percpu_counter: 16 cpus found Cleaning source tree... Caching kernel source in ram... No old config found, using defconfig Making mrproper Making defconfig... Kernel 2.6.16 Performing 5 runs of make -j 8 make -j 64 make -j All data logged to kernbench.log Warmup run... Half load -j 8 run number 1... Half load -j 8 run number 2... Half load -j 8 run number 3... Half load -j 8 run number 4... Half load -j 8 run number 5... Average Half load -j 8 Run (std deviation): Elapsed Time 120.68 (0.425558) User Time 583.488 (0.54099) System Time 84.716 (0.345948) Percent CPU 553 (2) Context Switches 13146.4 (66.3272) Sleeps 26998.2 (297.078) Optimal load -j 64 run number 1... Optimal load -j 64 run number 2... Optimal load -j 64 run number 3... Optimal load -j 64 run number 4... Optimal load -j 64 run number 5... Average Optimal load -j 64 Run (std deviation): Elapsed Time 86.496 (0.335827) User Time 809.699 (238.449) System Time 103.137 (19.423) Percent CPU 945.3 (413.544) Context Switches 32549.5 (20471.2) Sleeps 34308 (7795.17) Maximal load -j run number 1... Maximal load -j run number 2... Maximal load -j run number 3... Maximal load -j run number 4... Maximal load -j run number 5... Average Maximal load -j Run (std deviation): Elapsed Time 86.47 (0.321636) User Time 883.568 (219.647) System Time 108.728 (17.597) Percent CPU 1073.8 (381.226) Context Switches 31920.4 (16443.3) Sleeps 30472.5 (8402.01) ***** With atomic_long_t 16 cpus found Cleaning source tree... Caching kernel source in ram... No old config found, using defconfig Making mrproper Making defconfig... Kernel 2.6.16 Performing 5 runs of make -j 8 make -j 64 make -j All data logged to kernbench.log Warmup run... Half load -j 8 run number 1... Half load -j 8 run number 2... Half load -j 8 run number 3... Half load -j 8 run number 4... Half load -j 8 run number 5... Average Half load -j 8 Run (std deviation): Elapsed Time 120.468 (0.724134) User Time 581.226 (0.497624) System Time 84.358 (0.45417) Percent CPU 551.8 (3.19374) Context Switches 13085.6 (108.579) Sleeps 26965.8 (189.384) Optimal load -j 64 run number 1... Optimal load -j 64 run number 2... Optimal load -j 64 run number 3... Optimal load -j 64 run number 4... Optimal load -j 64 run number 5... Average Optimal load -j 64 Run (std deviation): Elapsed Time 86.25 (0.263439) User Time 805.828 (236.752) System Time 102.262 (18.8792) Percent CPU 942.7 (412.059) Context Switches 32339.7 (20299.6) Sleeps 34301.9 (7741.15) Maximal load -j run number 1... Maximal load -j run number 2... Maximal load -j run number 3... Maximal load -j run number 4... Maximal load -j run number 5... Average Maximal load -j Run (std deviation): Elapsed Time 85.868 (0.757905) User Time 879.129 (218.053) System Time 107.847 (17.2136) Percent CPU 1072.73 (381.349) Context Switches 31854.5 (16297.1) Sleeps 30436.2 (8399.98) 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?=
- 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: Andrew Morton <[email protected]>
- 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: Ravikiran G Thirumalai <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Arjan van de Ven <[email protected]>
- 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
- From: Laurent Vivier <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- From: Arjan van de Ven <[email protected]>
- Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
- Prev by Date: Re: [RFC PATCH 1/2] Makefile: export-symbol usage report generator.
- Next by Date: Re: [RT] bad BUG_ON in rtmutex.c
- 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):
 |