mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <pmckenne@us.ibm.com>
To: davidel@xmailserver.org (Davide Libenzi)
Cc: paulus@samba.org (Paul Mackerras),
	torvalds@transmeta.com (Linus Torvalds),
	linux-kernel@vger.kernel.org
Subject: Re: Re: RFC: patch to allow lock-free traversal of lists
Date: Sat, 13 Oct 2001 07:11:08 -0700 (PDT)	[thread overview]
Message-ID: <200110131411.f9DEBAK07090@eng4.beaverton.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.40.0110121834150.1505-100000@blue1.dev.mcafeelabs.com> from "Davide Libenzi" at Oct 12, 2001 05:54:36 PM PST

>> To set the record straight, the PPC architecture spec says that
>> implementations *can* speculate reads, but they have to make it look
>> as if dependent loads have a read barrier between them.
>>
>> And it isn't speculated reads that are the problem in the alpha case,
>> it's the fact that the cache can reorder invalidations that are
>> received from the bus.  That's why you can read the new value of p but
>> the old value of *p on one processor after another processor has just
>> done something like a = 1; wmb(); p = &a.
>
>I think that necessary condition to have a reordering of bus sent
>invalidations is to have a partitioned cache architecture.
>I don't see any valid reason for a cache controller of a linear cache
>architecture to reorder an invalidation stream coming from a single cpu.
>If the invalidation sequence for cpu1 ( in a linear cache architecture )
>is 1a, 1b, 1c, ... this case can happen :
>
>1a, 2a, 1b, 2b, 2c, 1c, ...
>|       |           |
>.........................
>
>but not this :
>
>1a, 2a, 2b, 1c, 2c, 1b, ...
>|           |       |
>...............><........

A split cache is certainly one way to get the updates reordered.  It is
not the only one.  As Linus pointed out earlier, value speculation can
have the same effect (though I do not believe that value speculation is
in the cards for the i386 architecture).

>> My impression from what Paul McKenney was saying was that on most
>> modern architectures other than alpha, dependent loads act as if they
>> have a read barrier between them.  What we need to know is which
>> architectures specify that behaviour in their architecture spec, as
>> against those which do that today but which might not do it tomorrow.
>
>Uhmm, an architecture that with  a = *p;  schedule the load of  *p  before
>the load of  p  sounds screwy to me.

Agreed, but value speculation could do just that.  However, value
speculation would be handled correctly by rmbdd() and by wmbdd(),
though the latter case relies on precise interrupts.

>The problem is that even if cpu1 schedule the load of  p  before the
>load of  *p  and cpu2 does  a = 1; wmb(); p = &a; , it could happen that
>even if from cpu2 the invalidation stream exit in order, cpu1 could see
>the value of  p  before the value of  *p  due a reordering done by the
>cache controller delivering the stream to cpu1.

Yep!  I did not create Alpha, I am just trying to help everyone understand
how to live with it.  ;-)

					Thanx, Paul

  parent reply	other threads:[~2001-10-13 14:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-10 15:24 [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion Paul McKenney
2001-10-10 16:58 ` Andrea Arcangeli
2001-10-10 17:25   ` Linus Torvalds
2001-10-12  5:06   ` Rusty Russell
2001-10-12 16:28     ` Linus Torvalds
2001-10-12 19:50       ` Al Dunsmuir
2001-10-13  7:38       ` Rusty Russell
2001-10-13 16:28         ` Re: RFC: patch to allow lock-free traversal of lists with insertion ^M Paul E. McKenney
2001-10-13 21:23           ` Rusty Russell
2001-10-13  1:07     ` [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion Paul Mackerras
2001-10-13  1:54       ` Davide Libenzi
2001-10-13  2:04         ` Linus Torvalds
2001-10-13  2:31           ` Davide Libenzi
2001-10-13  2:46             ` Davide Libenzi
2001-10-13  3:30             ` Linus Torvalds
2001-10-13  2:49         ` Paul Mackerras
2001-10-13 14:11         ` Paul E. McKenney [this message]
2001-10-13  2:00       ` Linus Torvalds
2001-10-13 13:54         ` [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists Alan Cox
2001-10-12  5:43 ` [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with Albert D. Cahalan
2001-10-12  8:28   ` Alex Bligh - linux-kernel
2001-10-12  8:51   ` Jonathan Lundell
2001-10-12  6:26 ` Paul Mackerras
2001-10-13 17:28 [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion Linus Torvalds
2001-10-14  2:04 ` Re: RFC: patch to allow lock-free traversal of lists Paul E. McKenney

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=200110131411.f9DEBAK07090@eng4.beaverton.ibm.com \
    --to=pmckenne@us.ibm.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®