Messages in this thread |  | | Date | Fri, 27 Oct 2000 03:13:33 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9) |
| |
On Fri, 27 Oct 2000, Jeff V. Merkey wrote:
> > Linux has lots of n-sqared linear list searches all over the place, and > there's a ton of spots I've seen it go linear by doing fine grained > manipulation of lock_kernel() [like in BLOCK.C in NWFS for sending async > IO to ll_rw_block()]. I could see where there would be many spots > where playing with this would cause problems. > > 2.5 will be better.
fs/locks.c is one hell of a sick puppy. Nothing new about that. I'm kinda curious about "n-squared" searches in other places, though - mind showing them?
BTW, what spinlocks get contention in variant without BKL? And what about comparison between the BKL and non-BKL versions? If it's something like BKL no BKL 4-way 50 20 8-way 30 30 - something is certainly wrong, but restoring the BKL is _not_ a win.
I didn't look into recent changes in fs/locks.c, but I have quite problem inventing a scenario when _adding_ BKL (without reverting other changes) might give an absolute improvement. Well, I see a couple of really perverted scenarios, but... Seriously, folks, could you compare the 4 variants above and gather the contention data for the -test9 on your loads? That would help a lot.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |