Hello, Maintainer.
I want use neon-intrinsics to built a neon version copy_page/clear_page
function. but I don’t know why other platform haven’t do this before. so
I send this email to ask is that correct?
BTW, I found a similar implementation in arch/x86/lib/mmx_32.c, any idea
welcome.
BR.
Jackie
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, 12 Dec 2018 at 07:01, JackieLiu [off-list ref] wrote:
Hello, Maintainer.
I want use neon-intrinsics to built a neon version copy_page/clear_page
function. but I don’t know why other platform haven’t do this before. so
I send this email to ask is that correct?
clear_page() uses DC ZVA instructions, so I doubt you'd be able to
improve on that with NEON stores.
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
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.
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?
在 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.
From: Robin Murphy <robin.murphy@arm.com> Date: 2018-12-12 11:45:39
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.
Thanks for your suggestion, maybe the problem is not on the copy_page,
I need to re-understand the fork function code, looking for the real bottleneck.
BR.
Jackie
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... :/
quoted
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
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.
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2018-12-12 12:22:17
On Wed, Dec 12, 2018 at 03:32:17PM +0800, 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.
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?
I don't see anything out of the ordinary or unexpected here. In
comparison to the rest of the work being done at and after fork(),
the most expensive bit _will_ be copying data around, so of course
this comes out high in the statistics.
However, UnixBench's spawn program is a system benchmark that allows
you to compare specific details of one implementation with another -
it is not supposed to be used to optimise a system. Why? It's not
a realistic workload.
Most programs either create threads (which are clones of another
thread, and share pages) or they fork() and then shortly later execve()
another program. In both cases, there is very little page copying.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel