From: Tim Chen <tim.c.chen@linux.intel.com>
To: Thad Phetteplace <tdphette@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Slow copy_to_user performance after kernel upgrade
Date: Fri, 28 Sep 2012 16:40:17 -0700 [thread overview]
Message-ID: <20120928234017.GA5280@linux.intel.com> (raw)
In-Reply-To: <CAOQSsQMY70nvzFT=rx0yqUXhm=fZWBi+ke-QuZj6uynfZmTLDw@mail.gmail.com>
On Fri, Sep 28, 2012 at 03:58:26PM -0500, Thad Phetteplace wrote:
> I am debugging an issue with copy_to_user performance on recent linux
> kernels. I've noticed a 4X slowdown in copy speed when I move from
> kernel 2.6.18 to more recent kernels on the same hardware. I've
> tested so far on 2.6.32 and on various 3.x kernels. I noticed that
> assembly code implementation of copy_to_user has changed, so as a
> sanity check I ported the 2.6.18 version over to 2.6.32 but saw the
> same slowdown when using it. This is the hardware I am using:
>
> Dell PowerEdge R710
> BIOS version 6.3.0
> Intel(R) Xeon(R) CPU x5650 @ 2.67GHz
> 72GB RAM (ECC DDR3 800MHz)
>
> I am running the x86_64 version of course. I see the issue when I do
> a copy_to_user from a dedicated block of memory located above the 4GB
> boundary into normal user space mem. The boot parameter mem=65G is
> passed to the kernel to carve off the dedicated block of memory that
> is used as a DMA accessible buffer for a specialized network card.
> That is the buffer we do the copy_to_user from. I should also mention
> we have been testing this on CentOS 4.8, 6.2, and 6.3, though I've
> replaced their stock kernels with ones straight from kernel.org, so I
> don't know that the linux distro is really relevant.
>
> I've browsed the kernel mailing list looking for clues and have even
> been looking at CPU/hardware specific errata, but so far I can see no
> logical reason why the 2.6.32+ kernels should be performing so much
> worse than the 2.6.18. Does anyone have any suggestions on areas to
> dig into besides the copy_to_user implementation itself? Maybe
> somewhere specific in the MMU code? Any suggestions would be
> appreciated. Please copy me directly on replies if you don't mind.
>
What cpu frequency governor are you using for testing? Perhaps
the default ondemand governor is not boosting the cpu frequency
when you are running yor benchmark?
If that's the case, try to rerun with performance governor.
Tim
prev parent reply other threads:[~2012-09-28 23:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 20:58 Slow copy_to_user performance after kernel upgrade Thad Phetteplace
2012-09-28 23:40 ` Tim Chen [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=20120928234017.GA5280@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tdphette@gmail.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