From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de ([195.135.220.2]:35049 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932513AbXLNAdr (ORCPT ); Thu, 13 Dec 2007 19:33:47 -0500 Subject: Re: RFC: remove __read_mostly From: Andi Kleen References: <20071213222044.GH21616@stusta.de> <20071213235432.GA26669@fattire.cabal.ca> Date: Fri, 14 Dec 2007 01:33:45 +0100 In-Reply-To: <20071213235432.GA26669@fattire.cabal.ca> (Kyle McMartin's message of "Thu\, 13 Dec 2007 18\:54\:32 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kyle McMartin Cc: Adrian Bunk , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Kyle McMartin 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