Messages in this thread | | | Date | Fri, 14 Mar 2003 23:05:11 -0800 | From | William Lee Irwin III <> | Subject | Re: [PATCH] concurrent block allocation for ext2 against 2.5.64 |
| |
William Lee Irwin III <wli@holomorphy.com> wrote: >> Looks like dbench doesn't scale. It needs to learn how to spread itself >> across disks if it's not to saturate a device queue while at the same >> time generating enough cpu load to saturate cpus.
On Fri, Mar 14, 2003 at 10:44:13PM -0800, Andrew Morton wrote: > Nope. What we're trying to measure here is pure in-memory lock contention, > locked bus traffic, context switches, etc, etc. To do that we need to get > the IO system out of the picture. > One way to do that is to increase /proc/sys/vm/dirty_ratio and > dirty_background_ratio to 70% or so. You can still hit IO wait if someone > tries to truncate a file which pdflush is writing out, so increase > dirty_expire_centisecs and dirty_writeback_centisecs to 1000000000 or so... > Then, on the second run, when all the required metadata blocks are in > pagecache you should be able to get an IO-free run.
Oh, sorry, I did increase dirty_ratio and dirty_background_ratio to 99, I forgot about dirty_writeback_centisecs though, I'll re-run with that.
William Lee Irwin III <wli@holomorphy.com> wrote: >> Is there a better (publicable/open/whatever) benchmark?
On Fri, Mar 14, 2003 at 10:44:13PM -0800, Andrew Morton wrote: > I have lots of little testlets which can be mixed and matched. RAM-only > dbench will do for the while. It is showing things. >
William Lee Irwin III <wli@holomorphy.com> wrote: >> dbench 128: >> Throughput 161.237 MB/sec 128 procs >> dbench 128 2>& 1 143.85s user 3311.10s system 1219% cpu 4:43.27 total >> vma samples %-age symbol name >> c0106ff4 9134179 33.7261 default_idle >> c01dc3b0 5570229 20.5669 __copy_to_user_ll >> c01dc418 1773600 6.54865 __copy_from_user_ll >> c0119058 731524 2.701 try_to_wake_up >> c0108140 686952 2.53643 .text.lock.semaphore >> c011a1bc 489415 1.80706 schedule >> c0119dac 485196 1.79149 scheduler_tick >> c011fadc 448048 1.65433 profile_hook >> c0119860 356065 1.3147 load_balance >> c0107d0c 267333 0.987072 __down >> c011c4ff 249627 0.921696 .text.lock.sched
On Fri, Mar 14, 2003 at 10:44:13PM -0800, Andrew Morton wrote: > The wakeup and .text.lock.semaphore load indicates that there is a lot > of contention for a semaphore somewhere. Still. > I'm not sure which one. It shouldn't be a directory semaphore. Might be > lock_super() in the inode allocator, but that seems unlikely.
I'm going to have to break out tools to decipher which one this is. hlinder forward-ported lockmeter so I'll throw that in the mix.
-- wli - 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/
| |