On Mon, 28 May 2012 14:58:42 +0300 Vlad Zolotarov <vlad@xxxxxxxxxxx> wrote: > From: Shai Fultheim <shai@xxxxxxxxxxx> > > bh_cachep is only written to once on initialization, so move it to the > __read_mostly section. > > Signed-off-by: Shai Fultheim <shai@xxxxxxxxxxx> > Signed-off-by: Vlad Zolotarov <vlad@xxxxxxxxxxx> > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
