On Monday 05 January 2009 05:41:03 Matthew Wilcox wrote: > On Sun, Jan 04, 2009 at 07:21:50PM +0100, Peter Zijlstra wrote: > > The -rt tree has adaptive spin patches for the rtmutex code, its really > > not all that hard to do -- the rtmutex code is way more tricky than the > > regular mutexes due to all the PI fluff. > > > > For kernel only locking the simple rule: spin iff the lock holder is > > running proved to be simple enough. Any added heuristics like max spin > > count etc. only made things worse. The whole idea though did make sense > > and certainly improved performance. > > That implies moving > > struct thread_info *owner; > > out from under the CONFIG_DEBUG_MUTEXES code. One of the original > justifications for mutexes was: > > - 'struct mutex' is smaller on most architectures: .e.g on x86, > 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. > A smaller structure size means less RAM footprint, and better > CPU-cache utilization. > > I'd be reluctant to reverse that decision just for btrfs. > > Benchmarking required! Maybe I can put a patch together that implements > the simple 'spin if it's running' heuristic and throw it at our > testing guys on Monday ... adaptive locks have traditionally (read: Linus says) indicated the locking is suboptimal from a performance perspective and should be reworked. This is definitely the case for the -rt patchset, because they deliberately trade performance by change even very short held spinlocks to sleeping locks. So I don't really know if -rt justifies adaptive locks in mainline/btrfs. Is there no way for the short critical sections to be decoupled from the long/sleeping ones? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
