From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 11/18] fs: Introduce per-bucket inode hash locks Date: Sat, 16 Oct 2010 18:57:03 +1100 Message-ID: <20101016075703.GO19147@amd> References: <1286515292-15882-1-git-send-email-david@fromorbit.com> <1286515292-15882-12-git-send-email-david@fromorbit.com> <20101008185409.GA29251@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: Content-Disposition: inline In-Reply-To: <20101008185409.GA29251@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 08, 2010 at 02:54:09PM -0400, Christoph Hellwig wrote: > > +struct inode_hash_bucket { > > + struct hlist_bl_head head; > > +}; > > + > > +static inline void spin_lock_bucket(struct inode_hash_bucket *b) > > +{ > > + bit_spin_lock(0, (unsigned long *)b); > > +} > > + > > +static inline void spin_unlock_bucket(struct inode_hash_bucket *b) > > +{ > > + __bit_spin_unlock(0, (unsigned long *)b); > > +} > > I've looked at the dcache version of this again, and I really hate > duplicating these helpers in the dcache code aswell. IMHO they > should simple operate directly on the hlist_bl_head, as that's > what it was designed for. I also don't really see any point in > wrapping the hlist_bl_head as inode_hash_bucket. If the bucket naming > is important we could rename the hlist_bl stuff to bl_hash, and the > hlist_bl_head could become bl_hash_bucket. It was done because someone, like -rt, might want more than one bit of memory to implement a lock. They would have to make a few other changes, granted, but this helps reduce a lot of churn. I didn't see the point of a layer of dumb wrappers for hlist_bl_head locking. Just reproducing bit spin and wait locks in wrappers when we already have good functions for them.