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: <20071216191730.GA15890@stusta.de>
Date:	Sun, 16 Dec 2007 20:17:30 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	Eric Dumazet <dada1@...mosbay.com>
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

On Sun, Dec 16, 2007 at 07:38:14PM +0100, Eric Dumazet wrote:
>
> 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.

How many patches do you want to send only for saving 120 bytes in some 
configurations (and even not the ones people who really care about the 
kernel size usually use)?

And most C files in the kernel would allow you to save more than
120 bytes if you don't mind how tihe source code looks like and e.g. 
don't mind turning it into an #ifdef mess.

If you care about the kernel size, you could e.g. help in fighting 
removals of unused EXPORT_SYMBOL's through Andrew instead - these are 
space saving patches that neither make the C code look worse nor can 
have negative impact on the generated code.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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