]> git.dujemihanovic.xyz Git - u-boot.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)
commit729c1fe656913f0d5b09e986fec9976020a3363c
tree0f55783252d3a4a408cdd3b2e2854ae6ae3702ae
parentec4cc0edf9c73ce65eaf669ad1b6b445c42844a0
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