Messages in this thread | | | Date | Sat, 20 Nov 2004 18:36:37 -0800 | From | Hans Reiser <> | Subject | Re: performance of filesystem xattrs with Samba4 |
| |
New benchmarks seem to be especially good at finding bugs.
vs, please find the bug and fix it.
Hans
tridge@samba.org wrote:
>Hans, > > > mkfs.reiser4 -o extent=extent40 > >This lowered the performance by a small amount (from 52 MB/sec to 50 >MB/sec). > >It also revealed a bug. I have been doing my tests on a cleanly >formatted filesystem each time, but this time I re-ran the test a few >times in a row to determine just how consistent the results are. The >results I got were: > > mkfs.reiser4 -o extent=extent40 50 MB/sec > 48 > 43 > 41 > 37 (stuck) > >the "stuck" result meant that smbd locked into a permanent D state at >the end of the fifth run. Unfortunately ps showed the wait-channel as >'-' so I don't have any more information about the bug. I needed to >power cycle the machine to recover. > >To check if this is reproducable I tried it again and got the following: > >reboot, mkfs again 50 MB/sec > 48 > 44 > 42 > 40 > (failed) > >the "failed" on the sixth run was smbd stuck in D state again, this >time before the run completed so I didn't get a performance number. > >I should note that the test completely wipes the directory tree >between runs, and the server processes restart, so the only way there >can be any state remaining that explains the slowdown between runs is >a filesystem bug. Do you think reiser4 could be "leaking" some on-disk >structures? > >To determine if this problem is specific to the extent=extent40 >option, I ran the same series of tests against reiser4 without the >extent option: > >reboot, mkfs.reiser4 without options 52 MB/sec > 52 > 45 > 41 > (failed) > >The failure on the fifth run showed the same symptoms as above. > >To determine if the bug is specific to reiser4, I then ran the same >series of tests against ext3, using the same kernel: > > reboot, mke2fs -j 70 MB/sec > 70 > 69 > 70 > 71 > 70 > >So it looks like the gradual slowdown and eventual lockup is specific >to reiser4. What can I do to help you track this down? Would you like >me to write a "howto" for running this test, or would you prefer to >wait till I have an emulation of the test in dbench? > >To give you an idea of the scales involved, each run lasts 100 >seconds, and does approximately 1 million filesystem operations (the >exact number of operations completed in the 100 seconds is roughly >proportional to the performance result). > > > >>Ah, that explains a lot. For that kind of workload, the simpler the fs >>the better, because really all you are doing is adding overhead to >>copy_to_user and copy_from_user. All of reiser4's advanced features >>will add little or no value if you are staying in ram. >> >> > >I'll do some runs with larger numbers of simulated clients and send >you those results shortly. Do you think a working set size of about >double the total machine memory would be a good size to start showing >the reiser4 features? > >Cheers, Tridge > > > >
- 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/
| |