From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH RESEND] fs: Move bh_cachep to the __read_mostly section Date: Thu, 7 Jun 2012 17:07:21 -0700 Message-ID: <20120607170721.474bd8d8.akpm@linux-foundation.org> References: <2325453.OX7ktP55U1@vlad> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Shai@scalemp.com To: Vlad Zolotarov Return-path: In-Reply-To: <2325453.OX7ktP55U1@vlad> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 28 May 2012 14:58:42 +0300 Vlad Zolotarov wrote: > From: Shai Fultheim > > bh_cachep is only written to once on initialization, so move it to the > __read_mostly section. > > Signed-off-by: Shai Fultheim > Signed-off-by: Vlad Zolotarov > --- > fs/buffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/buffer.c b/fs/buffer.c > index ad5938c..838a9cf 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -3152,7 +3152,7 @@ SYSCALL_DEFINE2(bdflush, int, func, long, data) > /* > * Buffer-head allocation > */ > -static struct kmem_cache *bh_cachep; > +static struct kmem_cache *bh_cachep __read_mostly; > hm, I thought I replied to this earlier, but I can't find that email. Yes, bh_cachep is read-mostly. In fact it's write-once. But the same is true of all kmem_cache*'s. I don't see any particular reason for singling out bh_cachep. Alas, I don't see a smart way of addressing this. It's either a patchset which adds __read_mostly to all kmem_cache*'s, or a patchset which converts all the definitions to use some nasty macro which inserts the __read_mostly. And I still have theoretical concerns with __read_mostly. As we further sort the storage into read-mostly and write-often sections, the density of writes in the write-mostly section increases. IOW, removing the read-mostly padding *increase* cross-CPU traffic in the write-often scction. IOW2, leaving the read-mostly stuff where it is provides beneficial padding to the write-often fields. I don't think it has been shown that there will be net gains.