From: Adrian Cox <adrian@humboldt.co.uk>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Worst case performance of up()
Date: Mon, 27 Nov 2006 21:02:16 +0000 [thread overview]
Message-ID: <1164661336.11001.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1164401124.5653.86.camel@localhost.localdomain>
On Sat, 2006-11-25 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2006-11-24 at 16:21 +0000, Adrian Cox wrote:
> > Does anybody have any ideas what could make up() take so long in this
> > circumstance? I'd expect cache transfers to make the operation about 100
> > times slower, but this looks like repeated cache ping-pong between the
> > two CPUs.
>
> Is it hung in up() (toplevel) or __up (low level) ?
Not yet proven.
> Have you tried some oprofile runs to catch the exact instruction where
> the cycles appear to be wasted ?
I've spent a day wrestling with oprofile, but I've not managed to
trigger the problem while profiling yet. It's possible that the slight
overhead of oprofile is enough to change the scheduling behaviour.
It remains an odd problem, and rather hard to reproduce. Unless I get
better data with oprofile this one may remain in the mystery file.
> Have you tried moving the semaphore away from whatever other data might
> be manipulated at the same time ? In it's own cache line maybe ?
I did try that, but it didn't make any difference.
--
Adrian Cox <adrian@humboldt.co.uk>
next prev parent reply other threads:[~2006-11-27 21:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-24 16:21 Worst case performance of up() Adrian Cox
2006-11-24 20:45 ` Benjamin Herrenschmidt
2006-11-27 21:02 ` Adrian Cox [this message]
2006-12-02 10:35 ` Adrian Cox
2006-12-02 11:15 ` Benjamin Herrenschmidt
2006-12-02 11:54 ` Adrian Cox
2006-12-02 20:52 ` Benjamin Herrenschmidt
2006-12-04 13:43 ` Adrian Cox
2006-12-04 20:25 ` Benjamin Herrenschmidt
2006-12-05 22:00 ` Benjamin Herrenschmidt
2006-12-08 2:33 ` Paul Mackerras
2006-12-08 3:10 ` Benjamin Herrenschmidt
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=1164661336.11001.9.camel@localhost.localdomain \
--to=adrian@humboldt.co.uk \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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).