lkml.org 
[lkml]   [2010]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 11/18] fs: Introduce per-bucket inode hash locks
From
On Mon, Oct 25, 2010 at 1:04 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 25 Oct 2010, Thomas Gleixner wrote:
>> On Mon, 25 Oct 2010, Nick Piggin wrote:
>> > Although a sane locking macro and structure like I had, would perfectly
>> > allow you to switch locks in a single place just the same.
>>
>> And a locking macro/structure is better in self documenting than a
>> helper function which was proposed by Christoph?
>
> Independently of what data structure you folks agree on, we really do
> _NOT_ want to have open coded bit_spin_*lock() anywhere in the code.
>
> As I said before, aside of RT it's a basic requirement to switch bit
> spinlocks to real ones for lockdep debugging.

Putting it in hlist_bl locking function doesn't do much to help --
putting mutexes
or spinlocks into hlist hashes is insane.

What might be good is to have a bit spinlock structure which is 0 size
in a normal
config, but it can hold things like lockdep data. Someone posted a patch maybe a
year ago to do that, which I thought was good but I don't know why it didn't go
anywhere.

It still doesn't solve your -rt problem really, because on a
production rt build like I
say, you can't blindly just replace bit spinlocks with mutexes. But it
makes lockdep
work and could take care of *some* bit spinlocks for -rt.


\
 
 \ /
  Last update: 2010-10-26 02:15    [W:0.145 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site