linux-kernel - Re: [PATCH RESEND] fs: Move bh_cachep to the __read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20120703142348.3c963378.akpm@linux-foundation.org>
Date:	Tue, 3 Jul 2012 14:23:48 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Chinmay V S <cvs268@...il.com>
Cc:	Vlad Zolotarov <vlad@...lemp.com>, viro@...iv.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Shai@...lemp.com
Subject: Re: [PATCH RESEND] fs: Move bh_cachep to the __read_mostly section

On Mon, 2 Jul 2012 23:54:09 +0530
Chinmay V S <cvs268@...il.com> wrote:

> Hi Vlad,
> 
> I suppose we both are looking at opposite sides of the same coin.
> While i am wary of the potential pitfalls,
> you have focused on the benefits of using __read_mostly.
> 
> At this point i would like to send out a shout to everyone concerned to please
> clarify the status of __read_mostly:
> 
> 1. Is it being actively pursued? (systems that *will* clearly benefit from it)
> 2. Any actual results on real world use-cases? (w/ & w/o __read_mostly)
> 3. Is __read_mostly being accepted in non-architecture specific kernel code?
> 4. Is anyone working on a potential replacement for it?

I don't recall ever having seen any serious work justifying or
condemning __read_mostly.  It's one of those things which seemed a good
idea at the time, got added and nobody did anything further with it, as
far as I know.  I've always been rather wobbly about it, for reasons
discussed up-thread.

As for this particular patch: I've not seen any reason to do anything
with it, because the changelog doesn't describe why the patch is
needed.  If some performance problem has been encountered then that
should have been fully described in the patch changelog.

If some problem has indeed been observed then an alternative to
__read_mostly is to pad bh_cachep to a cacheline boundary with
____cacheline_aligned_in_smp or similar.  Or, perhaps better, identify
the variable which bh_cachep is sharing with, and pad *that* variable
to a cacheline so it can't cause cache thrashing with something else in
the future.  And once this mystery variable is identified, we can
perhaps beneficially group it into the same cacheline with some other
variables which are related to it.

But I'm madly guessing and can't say aything dispositive or even
useful, because we haven't been told what the problem was.  Still.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/