[U-Boot] [PATCH] uboot optimize memmove

[Andy Green]

On 26 July 2013 20:58, Wolfgang Denk <wd at denx.de> wrote:
> Dear Andy Green,
>
> In message <20130726065323.27333.82421.stgit at localhost.localdomain> you wrote:
>> While studying the reason why kernel copy from NOR was so slow on our platform,
>> I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunks needlessly.
>>
>> bootm uses memmove() and that just takes the approach by default to move u8s
>> around.
>>
>> This optimization prefers memcpy() implementation (done mostly in 32-bit reads
>> and writes) if there's no overlap in source and dest, resulting in a huge
>> speedup on our platform (480ms copy from 32-bit NOR ---> 140ms)
>
> Sorry, but I dislike your patch.

I see.

> Instead of making assumptions on the performance of memcpy() and

As I wrote, I measured the performance and got a very big gain, it's >
3x faster on my setup to use memcpy() then default memmove().

By calling that an "assumption" you're saying that there exist
platforms where 32-bit linear memmove() is slower than doing it with
8-bit actions?

> adding the overhead of an additional function call (which can be
> expensive especially for short copy operations) it would make more

I am not sure U-Boot is really in the business of doing small
memmoves, but okay...

> sense to pull the "copy a word at a time" code from memcpy() into
> memmove(), too.
>
> On the other hand - if you really care about performance, then why do

I spent several hours figuring out why our NOR boot performance was
terrible.... it's because this default memmove code is gloriously
inefficient for all cases.

If you like it like that, no worries.

> you not make sure that you provide optimized implementations for such
> functions and consequently #define __HAVE_ARCH_MEMMOVE (and
> __HAVE_ARCH_MEMCPY) ?

Yes I found these afterwards... performance is slightly better than
memcpy() thanks to Nicolas Pitre it seems.  The U-Boot config for the
platform we have didn't know about them, it's much better with them.

After I wrote this patch it was also pointed out by Will Newton at
Linaro that we have Neon accelerated memcpy lying around with BSD
license....

https://launchpad.net/cortex-strings

however for my purposes NOR boot is working good enough with the ARCH versions.

-Andy

> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> It is dangerous to be sincere unless you are also stupid.
>                                                 - George Bernard Shaw