Re: [RANDOM] Move two variables to read_mostly section to savememory

From: Adrian Bunk
Date: Sun Dec 16 2007 - 14:17:39 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/