[PATCH] powerpc: reduce number of WATCHDOG_RESET calls from flush_cache

[Priyanka Jain (OSS)]

>-----Original Message-----
>From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Rasmus Villemoes
>Sent: Friday, September 18, 2020 1:51 PM
>To: Stefan Roese <sr at denx.de>; u-boot at lists.denx.de
>Cc: Christophe Leroy <christophe.leroy at c-s.fr>; Wolfgang Denk
><wd at denx.de>; Simon Glass <sjg at chromium.org>; Tom Rini
><trini at konsulko.com>
>Subject: Re: [PATCH] powerpc: reduce number of WATCHDOG_RESET calls
>from flush_cache
>
>On 04/06/2020 12.31, Stefan Roese wrote:
>> On 04.06.20 11:30, Rasmus Villemoes wrote:
>>> Calling WATCHDOG_RESET for each and every cache line is overkill.
>>>
>>> In our case, the kernel image is a little over 7MB, and the almost
>>> 500000 calls of WATCHDOG_RESET() adds about one second to the
>>> boottime.
>>>
>>> I very highly doubt there's any real hardware where flushing 64K from
>>> cache to memory takes more than a few milliseconds, so this should be
>>> completely safe. Since it reduces the number of
>>> WATCHDOG_RESET() calls by roughly a factor of 1000, the overhead from
>>> those is practically eliminated. (Just in case the range flushed is
>>> so small that it doesn't cross a 64K boundary, add a single
>>> WATCHDOG_RESET() between the loops).
>>>
>>> 64K is chosen because that's also the default chunk size used by the
>>> hashing algorithms, and when, say, a sha256 digest of a kernel image
>>> of a few MB is being verified, that's almost guaranteed to be
>>> cache-cold, so apart from the computations being done, the hashing is
>>> also bounded by memory speed - so if 64K works for those cases, it
>>> should certainly also work when memory access is the only thing being
>done.
>>>
>>> Signed-off-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
>>
>> Reviewed-by: Stefan Roese <sr at denx.de>
>
<snip>
Applied to u-boot-mpc85xx. Awaiting upstream

Thanks
Priyanka