From: Matthew W. <wi...@de...> - 2001-11-16 20:44:03
|
> Rick Lindsley wrote: > > A file-lock-intensive benchmark brought to my attention that the BKL is > > currently used to guard i_flock. Without arguing about the merits of > > this particular benchmark, it seems to me that simply from inspection, > > replacing the BKL here would be a good thing. A per-inode spinlock > > would give better granularity than a global one which will cause > > blockage across the system on every lock attempt by any process. I've > > given some thought to how to improve on that, and come up with to No arguments that the BKL needs to be removed here. I did exactly that at one point. I want to know about a real-world application which makes heavy use of file locks and might conceivably have its performance negatively impacted by a spinlock. Apache actually doesn't count. It should be recompiled to not use file locks for synchronisation; with linux 2.4, the wake-one semantics on normal wait queues will give it better performance. > > Both b) and c) cause serialization across every cpu in the system by > > using a global lock, but d) would cause serialization *per inode* and > > thus almost guarantee less contention. Not necessarily. Consider the case of a database using range locks on a big file. Per inode has no benefits compared to global. > > why I asked the question. Doing e) almost certainly puts it into the > > 2.5 timespace, but not 100% certainly, I suppose. Before I dig too deep > > into some test patches I thought I'd test the waters among the folks > > here in LSE. Er, hello? 2.4 is suppoed to be being STABILISED, not being REWRITTEN. If more people were concerned with this, we might be almost finished with 2.5 by now. I've been delaying my rewrite because of this. Seeing people like you ignore it really pisses me off. -- Revolutions do not require corporate support. |