That's great, thanks for your testing.
On 2024/6/11 20:45, Geert Uytterhoeven wrote:
Hi Yuntao,
On Sat, Mar 16, 2024 at 3:44 AM Yuntao Liu <liuyuntao12@xxxxxxxxxx> wrote:
The current arm32 architecture does not yet support the
HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in
embedded scenarios, and enabling this feature would be beneficial for
reducing the size of the kernel image.
In order to make this work, we keep the necessary tables by annotating
them with KEEP, also it requires further changes to linker script to KEEP
some tables and wildcard compiler generated sections into the right place.
When using ld.lld for linking, KEEP is not recognized within the OVERLAY
command, and Ard proposed a concise method to solve this problem.
It boots normally with defconfig, vexpress_defconfig and tinyconfig.
The size comparison of zImage is as follows:
defconfig vexpress_defconfig tinyconfig
5137712 5138024 424192 no dce
5032560 4997824 298384 dce
2.0% 2.7% 29.7% shrink
When using smaller config file, there is a significant reduction in the
size of the zImage.
We also tested this patch on a commercially available single-board
computer, and the comparison is as follows:
a15eb_config
2161384 no dce
2092240 dce
3.2% shrink
The zImage size has been reduced by approximately 3.2%, which is 70KB on
2.1M.
Signed-off-by: Yuntao Liu <liuyuntao12@xxxxxxxxxx>
Tested-by: Arnd Bergmann <arnd@xxxxxxxx>
Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx>
Thanks for your patch, which is now commit ed0f941022515ff4 ("ARM:
9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") in
arm/for-next (next-20240611).
I gave this a try on my custom configs for RSK+RZA1 (RZ/A1H)
and RZA2MEVB (RZ/A2M). According to bloat-o-meter, enabling
HAVE_LD_DEAD_CODE_DATA_ELIMINATION reduced kernel size by almost
500 KiB (-8.3%). The figures reported in "Memory: ... available"
were even more impressive: 1032 KiB more free memory than before.
As these boards have only 32 resp. 64 MiB of RAM, and some products
even use RZ/A1H with just the 10 MiB of on-chip SRAM, this is a good
improvement to have!
Thanks!
Tested-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
Gr{oetje,eeting}s,
Geert
