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

[Ravikiran G Thirumalai]

On Thu, Apr 13, 2006 at 05:26:39PM +0200, Laurent Vivier wrote:
> Le lun 10/04/2006 à 10:24, Andrew Morton a écrit :
> > Laurent Vivier <Laurent.Vivier@xxxxxxxx> wrote:
> > >
> > > Does the attached patch look like the thing you though about ?
> > 
> > I guess so.  But it'll need a lot of performance testing on big SMP
> > to work out what the impact is.
> 
> I made some tests with dbench:
> 
> IBM x440: 8 CPUs hyperthreaded = 16 CPUs (Xeon at 1.4 Ghz)
> 

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,

With atomic counters, 32 clients, 3 runs
Throughput 187.712 MB/sec 32 procs
Throughput 197.059 MB/sec 32 procs
Throughput 203.522 MB/sec 32 procs

Without atomic counters (per-cpu counters), 32 clients, 3 runs
Throughput 228.805 MB/sec 32 procs
Throughput 155.831 MB/sec 32 procs
Throughput 134.777 MB/sec 32 procs

The oprofile profiles for the atomic counter case looks like this:

CPU: P4 / Xeon with 2 hyper-threads, speed 3002.77 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not
stopped) with a unit mask of 0x01 (mandatory) count 100000
samples  %        app name                 symbol name
180505286 57.7844  vmlinux-t                poll_idle
51944524 16.6288  vmlinux-t                ext3_test_allocatable
43648955 13.9731  vmlinux-t                bitmap_search_next_usable_block
2892251   0.9259  vmlinux-t                copy_user_generic
2099969   0.6723  vmlinux-t                do_get_write_access
1459523   0.4672  vmlinux-t                journal_dirty_metadata
1393413   0.4461  vmlinux-t                journal_stop

So the atomic counters in question are not even hotspots on this workload,
so IMHO, dbench cannot be used to come to any conclusion regarding per-cpu
counters vs atomics here.

Thanks,
Kiran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/