From: "Scott L. Burson" <gyro@zeta-soft.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Mathieu.Malaterre@creatis.insa-lyon.fr
Subject: Re: Spinlock performance on Athlon MP (2.4)
Date: Fri, 1 Aug 2003 12:44:35 -0700 (PDT) [thread overview]
Message-ID: <16168.30492.825111.621520@kali.zeta-soft.com> (raw)
In-Reply-To: <1059605940.10447.16.camel@dhcp22.swansea.linux.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: 30 Jul 2003 23:59:00 +0100
On Mer, 2003-07-30 at 22:50, Scott L. Burson wrote:
> First, and probably the reason you haven't heard more complaints about the
> problem, its severity is evidently dependent on the size of main memory. At
> 512MB it doesn't seem to be much of a problem (right, Mathieu?). At 2.5GB,
> which is what I have, it can be quite serious. For instance, if I start two
> `find' processes at the roots of different filesystems, the system can spend
> (according to `top') 95% - 98% of its time in the kernel. It even gets
> worse than that, but `top' stops updating -- in fact, the system can seem
> completely frozen, but it does recover eventually. Stopping or killing one
> of the `find' processes brings it back fairly quickly, though it can take a
> while to accomplish that.
Thats the well understood DMA bounce buffers problem.
It's definitely not the bounce buffers problem. I installed the patch and
it doesn't help (well, maybe it helps a little; it's hard to tell).
However, I have pretty strong evidence that it's not the spinlock handoff
time either. I wrote a small benchmark that starts two threads that do
nothing but hand two spinlocks back and forth. The Athlon runs it an order
of magnitude _faster_ than the P4 (5ns vs. 50ns, roughly, per handoff).
I'm fairly certain that lock contention is involved somehow, though.
Lockmeter reports that lock waiting is consuming about 35% of the CPU cycles
when the problem is happening. This isn't the 90% - 95% number I expected
-- the latter being the percentage of time spent in the kernel, as reported
by `top' -- but it's high enough to wonder about, and it may be artificially
low. Lockmeter has a spinlock that protects its data structures, and the
profile says 36% of the time is being spent in the routine that acquires
that lock. This suggests that lockmeter isn't counting that time.
One oddity pointed up by lockmeter is that `pagemap_lru_lock' is held by
`shrink_cache' some 85% of the time. This seems way too high, and I am
looking into it.
-- Scott
next prev parent reply other threads:[~2003-08-01 19:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-30 21:50 Spinlock performance on Athlon MP (2.4) Scott L. Burson
2003-07-30 22:59 ` Alan Cox
2003-08-01 19:44 ` Scott L. Burson [this message]
2003-07-31 15:25 ` Mathieu Malaterre
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=16168.30492.825111.621520@kali.zeta-soft.com \
--to=gyro@zeta-soft.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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).