From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: JackieLiu <liuyun01@kylinos.cn>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Andrew Pinski <apinski@cavium.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: Built a neon version copy_page/clear_page is correct?
Date: Wed, 12 Dec 2018 12:21:42 +0000 [thread overview]
Message-ID: <20181212122142.GM30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <370722B9-5CAE-4420-9126-3DF805BC115B@kylinos.cn>
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
prev parent reply other threads:[~2018-12-12 12:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-12 6:01 Built a neon version copy_page/clear_page is correct? JackieLiu
2018-12-12 7:18 ` Ard Biesheuvel
2018-12-12 7:32 ` JackieLiu
2018-12-12 11:45 ` Robin Murphy
2018-12-12 11:58 ` JackieLiu
2018-12-12 12:21 ` Russell King - ARM Linux [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181212122142.GM30658@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=apinski@cavium.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=liuyun01@kylinos.cn \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).