Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-13 23:02:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/powerpc/lib/Kconfig

10 lines
407 B
Text
Raw Normal View History

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>
2021-04-21 09:16:03 +00:00
config CACHE_FLUSH_WATCHDOG_THRESHOLD
powerpc: Fix flush_cache() speed regression Flushing kernel image after decompression was taking 113 milliseconds with U-boot 2022.10. With U-boot 2023.01 and 2023.04, flushing the same amount of memory takes approx 1.5 seconds. With U-boot 2023.07-rc6, it takes 6.5 seconds. powerpc flush_cache() function used to call WATCHDOG_RESET() after flushing every cacheline. At that time WATCHDOG_RESET() was light so the operation was almost seamless. But commit 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") replaced WATCHDOG_RESET() by schedule() and that started to hurt with U-boot 2022.10. And in U-boot 2023.07-rc6 that's even worse after commit 26e8ebcd7cb ("watchdog: mpc8xxx: Make it generic"). In the meantime commit 729c1fe656 ("powerpc: introduce CONFIG_CACHE_FLUSH_WATCHDOG_THRESHOLD") gives us the opportinity to only call schedule() every given chunk of data instead of every cacheline. As explained in that commit there is no point in pinging the watchdog after every cacheline flush, so lets define a sensible default chunk size of 4k which matches to size of a page on most powerpc platforms. With that new default threshold, the culprit flushing performed after kernel image decompression now takes 85 milliseconds on a powerpc 8xx. Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2023-07-05 14:51:37 +00:00
int "Bytes to flush between schedule() calls"
default 4096
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>
2021-04-21 09:16:03 +00:00
help
The flush_cache() function periodically, and by default for
powerpc: Fix flush_cache() speed regression Flushing kernel image after decompression was taking 113 milliseconds with U-boot 2022.10. With U-boot 2023.01 and 2023.04, flushing the same amount of memory takes approx 1.5 seconds. With U-boot 2023.07-rc6, it takes 6.5 seconds. powerpc flush_cache() function used to call WATCHDOG_RESET() after flushing every cacheline. At that time WATCHDOG_RESET() was light so the operation was almost seamless. But commit 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") replaced WATCHDOG_RESET() by schedule() and that started to hurt with U-boot 2022.10. And in U-boot 2023.07-rc6 that's even worse after commit 26e8ebcd7cb ("watchdog: mpc8xxx: Make it generic"). In the meantime commit 729c1fe656 ("powerpc: introduce CONFIG_CACHE_FLUSH_WATCHDOG_THRESHOLD") gives us the opportinity to only call schedule() every given chunk of data instead of every cacheline. As explained in that commit there is no point in pinging the watchdog after every cacheline flush, so lets define a sensible default chunk size of 4k which matches to size of a page on most powerpc platforms. With that new default threshold, the culprit flushing performed after kernel image decompression now takes 85 milliseconds on a powerpc 8xx. Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2023-07-05 14:51:37 +00:00
every 4k block, calls schedule() to reset watchdog. When
flushing a large area, that may add a significant amount of
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>
2021-04-21 09:16:03 +00:00
overhead. This option allows you to set a threshold for how
powerpc: Fix flush_cache() speed regression Flushing kernel image after decompression was taking 113 milliseconds with U-boot 2022.10. With U-boot 2023.01 and 2023.04, flushing the same amount of memory takes approx 1.5 seconds. With U-boot 2023.07-rc6, it takes 6.5 seconds. powerpc flush_cache() function used to call WATCHDOG_RESET() after flushing every cacheline. At that time WATCHDOG_RESET() was light so the operation was almost seamless. But commit 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") replaced WATCHDOG_RESET() by schedule() and that started to hurt with U-boot 2022.10. And in U-boot 2023.07-rc6 that's even worse after commit 26e8ebcd7cb ("watchdog: mpc8xxx: Make it generic"). In the meantime commit 729c1fe656 ("powerpc: introduce CONFIG_CACHE_FLUSH_WATCHDOG_THRESHOLD") gives us the opportinity to only call schedule() every given chunk of data instead of every cacheline. As explained in that commit there is no point in pinging the watchdog after every cacheline flush, so lets define a sensible default chunk size of 4k which matches to size of a page on most powerpc platforms. With that new default threshold, the culprit flushing performed after kernel image decompression now takes 85 milliseconds on a powerpc 8xx. Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2023-07-05 14:51:37 +00:00
many bytes to flush between each schedule() call.
Reference in a new issue Copy permalink