linux-kernel - Re: RFC: remove __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 for Android: free password hash cracker in your pocket

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

Message-ID: <p73tzmmf72u.fsf@bingen.suse.de>
Date:	Fri, 14 Dec 2007 01:33:45 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Kyle McMartin <kyle@...artin.ca>
Cc:	Adrian Bunk <bunk@...nel.org>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: RFC: remove __read_mostly

Kyle McMartin <kyle@...artin.ca> writes:

> I'd bet, in the __read_mostly case at least, that there's no
> improvement in almost all cases.

I bet you're wrong. Cache line behaviour is critical, much more
than pipeline behaviour (which unlikely affects). That is because
if you eat a cache miss it gets really expensive, which e.g.
a mispredicted jump is relatively cheap in comparison. We're talking
one or more orders of magnitude.

I admit I'm to blame for both (submitted unlikely and asked for
__read_mostly) and I now consider unlikely a mistake now by hindsight,
but still think __read_mostly was a good idea.

There is one potential problem in that if __read_mostly is used too
aggressively then the non __read_mostly variables will be all "write
mostly" with nothing inbetween and that could lead to more false
sharing, but so far this doesn't seem to be a big problem (and that
one could be solved too)

-Andi
--
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/