]> 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>
Wed, 28 Apr 2021 08:05:13 +0000 (10:05 +0200)
commit4b37a83dc4a296eeaf77f8fb981728b76c1a440d
tree0f55783252d3a4a408cdd3b2e2854ae6ae3702ae
parentb18352f2bacf2d13623c75f556d0bf6bffef1bce
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