From: Ralf Baechle <ralf@linux-mips.org>
To: David Daney <ddaney@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] MIPS: Optimize spinlocks.
Date: Thu, 25 Feb 2010 15:15:49 +0100 [thread overview]
Message-ID: <20100225141548.GB29565@linux-mips.org> (raw)
In-Reply-To: <4B8559F0.6080908@caviumnetworks.com>
On Wed, Feb 24, 2010 at 08:55:12AM -0800, David Daney wrote:
> It is possible that by choosing a better nudge_writes()
> implementation for R10K, that the 3% degradation could be erased.
> Perhaps:
>
> #define nudge_writes() do { } while (0)
raw_spin_unlock must provide a barrier so this wouldn't be a valid
implementation for nudge_writes(). Implementing it as barrier() this
is a pure compiler barrier is the most liberal valid implementation.
> Basically you want something that is fast, but that also forces the
> write to be globally visible as soon as possible. Some processors
> have a prefetch instruction that does this. On other processors a
> NOP is optimal as they don't combine writes in the write back
> buffer.
>
> There is a wbflush() function that could potentially be used, but
> its implementation is too heavy on Octeon.
For IP27 which is a strongly ordered system nudge_writes() is implemented
as barrier().
Another experiment I did was alignment. A branch on an R10000 has a
significant execution time penalty if it's delay slot is overlapping a
128 byte S-cache boundary. Suitable alignment however didn't not seem
to make any difference at all on R10000.
Ralf
next prev parent reply other threads:[~2010-02-25 14:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 19:31 [PATCH] MIPS: Optimize spinlocks David Daney
2010-02-24 15:53 ` Ralf Baechle
2010-02-24 15:54 ` Ralf Baechle
2010-02-24 16:55 ` David Daney
2010-02-25 14:15 ` Ralf Baechle [this message]
2010-02-25 17:31 ` David Daney
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=20100225141548.GB29565@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=ddaney@caviumnetworks.com \
--cc=linux-mips@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.