Re: Built a neon version copy_page/clear_page is correct?

On 12/12/2018 07:32, JackieLiu wrote:

Yes. I have a bottleneck, maybe it’s not copy_page’s. but
during the debugging process, this function has a very high
CPU utilization.

The test program is UnixBench’s src/spawn.c, with a while to
fork process. The only variable for test is PAGE_SIZE, one is
4k PAGE_SIZE, next is 64k PAGE_SIZE.

AFAICS all that does is call fork() in a loop as fast as it possibly 
can. Forking involves copying pages, either during the call or via 
copy-on-write triggering in one or both processes after the syscall 
returns. So your 'problem' is that some benchmark code spends a fair 
amount of time doing the major part of the operation it's benchmarking... :/

result for "perf top":
4k  |  13% CPU  copy_page
64k |  48% CPU  copy_page

This is why I want to optimize this function. Maybe bottleneck
is not here?

Also bear in mind that AFAIK most current cores can happily saturate 
their load/store unit with just LDP/STP - this isn't like Armv7 where 
VLD* was the only way to generate a single 128-bit wide access. If 
you're not doing any actual calculation or LDn/STn interleaving 
trickery, using NEON purely to move data is unlikely to be worthwhile in 
general. On many cores it may well end up being slower.

Robin.

quoted

在 2018年12月12日，15:18，Ard Biesheuvel [off-list ref] 写道：

As for copy_page(), please describe a use case where it is a
bottleneck, and reason about how much you could improve performance in
that case by improving the speed of copy_page() itself. Otherwise,
we're just adding NEON routines for the sake if it, which is a bad
idea imo.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel