From: Juergen D. <JD...@de...> - 2001-07-16 11:47:20
|
Hi, --- Anton Blanchard wrote > > Now we moved to kernel 2.4.4 and tested two patches for improving > > spinlock behaviour: > > > > o page_cache lock > > from Ingo Molnar's Redhat site (http://people.redhat.com/mingo) > > o kmap lock > > replied from Mark Hemment on the Lse-tech mailing list (06/15/2001). > > I recently did some benchmarking on a 16 way ppc64 machine. After > applying the pagecache lock patch, I found slight improvements cacheline > aligning some of the hotter locks. I also removed the BKL from sys_lseek > and instead used the inode semaphore to synchronise, I can create a > patch if you want to try it. > > By this stage the dcache lock, BKL in ext2 operations and lru_list_lock > were the main offenders. There isnt much that can be done about the dcache > lock and the BKL usage in ext2 will be fixed by the fs guys in 2.5. I > havent looked at the lru_list_lock yet. Can you create a patch with the cacheline aligned locks? I tried already removing the kernel_lock/unlock call in llseek in fs/read_write.c (without replacement). But this got no improvement for dbench. I did not understand why there is a lock at all. I could not detect a comparable lock in sys_write and sys_read and its descendants. Juergen jd...@de... |
From: Juergen D. <JD...@de...> - 2001-07-16 11:48:01
|
Hi, --- John Hawkes wrote > From: "Juergen Doelle" <JD...@de...> > >...snip... > > My impression is that additional workload from a measuring tool like > > lockmeter changes the system behavior, so that the results with > > lockmeter running do not reflect the situation when lockmeter is > > not running. > > Yes, this is quite likely. Even when a lockmeter-capable kernel has > lockmeter turned off, the spinlock/rwlock calls are still procedure > calls instead of inline asm. I would hope you're doing the basic > benchmarking using a non-lockmeter-patched kernel, and only using > lockmeter-capable and kernprof-capable kernels to peer into kernel > behavior to understand the basic benchmark results. (I don't recommend > using a kernel with both the lockmeter and kernprof patches, as the > totality of system perturbation is just too large.) > > John Hawkes > ha...@en... Of course, a kernel with lockmeter patch was only used for the lockmeter measurements. Benchmarking was done with a plain vanilla 2.4.4 kernel and the described lock patches. To make it clearer: My impression is that in this particular case the additional workload/ overhead from lockmeter has changed the system behavior. The lock behaviour with lockmeter running seem not to reflect the situation when lockmeter is not installed. The cause for that impression is that lockmeter reports a great improvement: one CPU was freed from spinning, but the throughput values (from a kernel without lockmeter patch) does only increase slighty. Juergen jd...@de... |