linux-kernel - Re: [RANDOM] Move two variables to 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: <47657096.50302@cosmosbay.com>
Date:	Sun, 16 Dec 2007 19:38:14 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RANDOM] Move two variables to read_mostly section to save	memory

Adrian Bunk a écrit :
> On Sun, Dec 16, 2007 at 06:42:57PM +0100, Eric Dumazet wrote:
>> Adrian Bunk a écrit :
>> ...
>>> And even more funny, with gcc 4.2 and CONFIG_CC_OPTIMIZE_FOR_SIZE=y your 
>>> patch doesn't seem to make any space difference - are you using an older 
>>> compiler or even worse CONFIG_CC_OPTIMIZE_FOR_SIZE=n for being able to see 
>>> any space difference?
>>>
>>> In both cases your code uglification would be even more pointless...
>>>
>> I believe that CONFIG_SMP is uglification for you Adrian, but still I am 
>> glad linux have it.
>>
>> If your CONFIG_SYSCTL=n is really that important for you, why dont you 
>> define a new qualifier that can indeed mark some variables as :
>>
>> const if CONFIG_SYSCTL=n
>> read_mostly if CONFIG_SYCTL=y
>>
>> This way you can keep compiler optimizations for your CONFIG_SYCTL=n, while 
>> many people like me can still continue to optimize their kernel.
>>
>> Seeing so many sysctl already read_mostly in kernel, I wonder why you NACK 
>> my patch, while it's easy to share your concerns with other people and find 
>> a solution.
> 
> You omitted an answer to my main important point...
> 
> Let me ask it in a more simple way:
> 
> Do you see any space difference at all with gcc 4.2 and 
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y ?
> 


I am using gcc-4.2.1

CONFIG_CC_OPTIMIZE_FOR_SIZE=y makes no difference for me.

$ make defconfig
$ egrep "OPTIMIZE_FOR_SIZE|CONFIG_SMP" .config
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SMP=y
$ make vmlinux
$ nm -v vmlinux|grep -4 random_read_wakeup_thresh
c057a02c d excluded_id_list
c057a100 d zero_bdi
c057a180 D random_table
c057a300 d input_pool
c057a400 d random_read_wakeup_thresh
c057a404 d random_write_wakeup_thresh
    <SAME HOLE HERE>
c057a480 d blocking_pool
c057a580 d nonblocking_pool
c057a680 d rekey_work

After my patch, I still gain 120 bytes.

Please realize that most people now build their kernels with CONFIG_SMP=y, or 
use a distro one (with CONFIG_SMP=y as well)

Your CONFIG_SYSCTL point is valid and should be addressed by a separate patch set.
--
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/