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: Mon, 25 Oct 2010 18:06:26 -0600 Message-ID: References: <20101016075703.GO19147@amd> <20101016161642.GC16861@infradead.org> <20101016171213.GC3240@amd> <20101017004610.GB29677@dastard> <20101017022539.GA3317@amd> <87iq0za32l.fsf@basil.nowhere.org> <20101018162105.GB9571@infradead.org> <20101019070057.GA7770@amd> <20101019165044.GA13531@infradead.org> <20101024211735.GB3137@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Nick Piggin , Christoph Hellwig , Andi Kleen , Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Thomas Gleixner Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:38706 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757929Ab0JZAG2 convert rfc822-to-8bit (ORCPT ); Mon, 25 Oct 2010 20:06:28 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Oct 24, 2010 at 10:41 PM, Thomas Gleixner = wrote: > On Mon, 25 Oct 2010, Nick Piggin wrote: >> You do not want to add a bloated mutex to each inode hash bucket and >> think you can just dust off your hands and walk away. =A0You would >> probably make a smaller auxiliary hash of locks, sanely sized, and >> protect it with that. >> >> So it would be wrong to just bloat hlist_bl by a factor of several t= imes >> (how big is a mutex in -rt?) without doing anything else. > > Let me worry about it. No, because you simply should almost never turn the hlist locking into = anything big and bloated, whether it is for -rt or anything else. It is most likely going to be used as a per-bucket hash lock (or bit of metadata), so anything larger than a bit (which is essentially free) is way overkill. You would instead have an auxiliary small hash of locks, not tens of me= gs of mutexes. >> Although a sane locking macro and structure like I had, would perfec= tly >> 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? Yes, because you still have the problem that you need to go through and= fix up all call sites. With my abstraction, there is a small inode function for locking an ino= de hash bucket. You have to change 2 places (lock and unlock) to look up an aux= hash of locks and you're done. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html