]> git.baikalelectronics.ru Git - uboot.git/commit
powerpc: introduce CONFIG_CACHE_FLUSH_WATCHDOG_THRESHOLD
authorRasmus Villemoes <rasmus.villemoes@prevas.dk>
Wed, 21 Apr 2021 09:16:03 +0000 (11:16 +0200)
committerStefan Roese <sr@denx.de>
Tue, 27 Apr 2021 06:28:07 +0000 (08:28 +0200)
commite29a693342e43dd43547e9f3ce3c01e6378e72f5
tree0f55783252d3a4a408cdd3b2e2854ae6ae3702ae
parent92a71eef3950ac8653ecfcaded7efe84e501c54c
powerpc: introduce CONFIG_CACHE_FLUSH_WATCHDOG_THRESHOLD

When flush_cache() is called during boot on our ~7M kernel image, the
hundreds of thousands of WATCHDOG_RESET calls end up adding
significantly to boottime. Flushing a single cache line doesn't take
many microseconds, so doing these calls for every cache line is
complete overkill.

The generic watchdog_reset() provided by wdt-uclass.c actually
contains some rate-limiting logic that should in theory mitigate this,
but alas, that rate-limiting must be disabled on powerpc because of
its get_timer() implementation - get_timer() works just fine until
interrupts are disabled, but it just so happens that the "big"
flush_cache() call happens in the part of bootm where interrupts are
indeed disabled. [1] [2] [3]

I have checked with objdump that the generated code doesn't change
when this option is left at its default value of 0: gcc is smart
enough to see that the ">=" comparison is tautologically true, hence
all assignments to "flushed" are eliminated as dead stores.

On our board, setting the option to something like 65536 ends up
reducing total boottime by about 0.8 seconds.

[1] https://patchwork.ozlabs.org/project/uboot/patch/20200605111657.28773-1-rasmus.villemoes@prevas.dk/
[2] https://lists.denx.de/pipermail/u-boot/2021-April/446906.html
[3] https://lists.denx.de/pipermail/u-boot/2021-April/447280.html

Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
arch/powerpc/Kconfig
arch/powerpc/lib/Kconfig [new file with mode: 0644]
arch/powerpc/lib/cache.c