Messages in this thread | | | Date | Mon, 25 Oct 2010 18:12:40 -0600 | Subject | Re: [PATCH 11/18] fs: Introduce per-bucket inode hash locks | From | Nick Piggin <> |
| |
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.
| |