From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934166AbXLMWs6 (ORCPT ); Thu, 13 Dec 2007 17:48:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758216AbXLMWsr (ORCPT ); Thu, 13 Dec 2007 17:48:47 -0500 Received: from gw1.cosmosbay.com ([86.65.150.130]:50902 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755331AbXLMWsq (ORCPT ); Thu, 13 Dec 2007 17:48:46 -0500 Message-ID: <4761B6BB.1070504@cosmosbay.com> Date: Thu, 13 Dec 2007 23:48:27 +0100 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adrian Bunk CC: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: RFC: remove __read_mostly References: <20071213222044.GH21616@stusta.de> In-Reply-To: <20071213222044.GH21616@stusta.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [86.65.150.130]); Thu, 13 Dec 2007 23:48:34 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adrian Bunk a écrit : > I tried the following patch with a full x86 .config [1]: > > --- a/include/asm-x86/cache.h > +++ b/include/asm-x86/cache.h > -#define __read_mostly __attribute__((__section__(".data.read_mostly"))) > +/* #define __read_mostly __attribute__((__section__(".data.read_mostly"))) */ > > The result [2,3] was: > > -rwxrwxr-x 1 bunk bunk 46607243 2007-12-13 19:50 vmlinux.old > -rwxrwxr-x 1 bunk bunk 46598691 2007-12-13 21:55 vmlinux > > It's not a surprise that the kernel can become bigger when __read_mostly > gets used, especially in cases where __read_mostly prevents gcc > optimizations. > > My question is: > Is there anywhere in the kernel a case where __read_mostly brings a > measurable improvement or can it be removed? Yes, there are many cases where read_mostly brings huge improvements. I did test your idea on a 4 CPUS server, and system time was roughly doubled, from 11% to 20% Of course, you noticed that puting a __read_mostly attribute force the linker to reserve space for the variable. So a null variable previously in bss section (no space in vmlinux file) is now in .data.read_mostly. Not a big deal. If you want, you could play some .lds games to create sort of a "bss.read_mostly" section to save 10000 bytes in vmlinux.