Linux PARISC architecture development
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>,
	parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] coherent ops and mb() revisited
Date: 08 Sep 2004 13:11:12 -0400	[thread overview]
Message-ID: <1094663473.7149.136.camel@mulgrave> (raw)
In-Reply-To: <20040908165210.GA10316@colo.lackof.org>

On Wed, 2004-09-08 at 12:52, Grant Grundler wrote:
> Yeah - there is a tradeoff between optimizing the pipeline between
> cases where the lock is contended and where it is not. The compiler
> does not have that info unless it could consume Profile info.
> (ie "Profile Based Optimization").
> I was thinking we should favor the contended case to make it
> less painful. I've changed my mind and will not push this patch.

Erm, no, optimisation of the pipeline is something different again.  If
we want to hint to the compiler that the lock will be uncontended, then
our code should read:

        while (unlikely(__ldcw(a) == 0))
                while (likely(*a == 0));


> But the _ldcw() is part of a tight "while" loop.
> What's the penalty for "crossing" the barrier?
> I don't see one.

In this case, probably not much ... it would forbid clever optimisations
of the while loops, but I'm sure the compiler isn't actually optimising
them very much.  However, the *principle* is that you want your barriers
where they're effective but do the least damage to the compiler's
ability to optimise.

> BTW, do you think we should use coherent loads/stores for locks?
> That's the other aspect of the patch that I think jda would like
> to see incorporated.

I'm not really sure what the coherent hint actually does.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2004-09-08 17:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-05  1:38 [parisc-linux] coherent ops and mb() revisited Grant Grundler
2004-09-05  2:56 ` James Bottomley
2004-09-05  6:27   ` John David Anglin
2004-09-05 14:36     ` James Bottomley
2004-09-06  4:19       ` Grant Grundler
2004-09-06  9:24         ` John David Anglin
2004-09-06 14:15         ` James Bottomley
2004-09-07 15:17           ` Grant Grundler
2004-09-07 15:30             ` James Bottomley
2004-09-08 16:52               ` Grant Grundler
2004-09-08 17:11                 ` James Bottomley [this message]
2004-09-10 16:11                   ` Grant Grundler

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=1094663473.7149.136.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@parisc-linux.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