mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@osdl.org>,
	torvalds@osdl.org, nickpiggin@yahoo.com.au
Cc: dhowells@redhat.com, inux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Document Linux's memory barriers [try #5]
Date: Thu, 16 Mar 2006 11:50:12 +0000	[thread overview]
Message-ID: <21253.1142509812@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060315200956.4a9e2cb3.akpm@osdl.org>

Andrew Morton <akpm@osdl.org> wrote:

> >  The attached patch documents the Linux kernel's memory barriers.
> 
> Thanks for doing this.  Is it all settled now?

More or less, I think; but Nick has raised a good point about whether I should
be mentioning the existence of things like caching at all in the document,
except to say that memory barriers can't be assumed to have any effect on them.

The problem is that if I don't mention caches, I get lots of arguments about
the effects locking primitives have (since in modern CPUs these happen within
the caches and not much within memory). I can't just say these things affect
memory because it's just not necessarily true:-/

Basically, there's two levels on which someone could be attempting to use this
document: either they could have no interest in the way things work, and just
want a list of guarantees and may-not-assumes; or they may be interested in
*why* the things in this list are in this list - this is fairly important for
arch developers and maintainers, I think.

Maybe I should split the document into two or three:

 (1) A basic list of guarantees and may-not-assumes when using memory barriers,
     and why memory barriers are required.

 (2) Maybe a separate document on I/O barriers.

 (3) A specification of an abstract/base/whatever CPU model that people must
     assume the CPU they're using works like. In practice, any particular real
     CPU will probably be more restrictive than that, but generally that's not
     a problem. The problems come when CPUs are _less_ restrictive than the
     model.

     Such a document could be extended to cover more than just memory barriers.

David

  reply	other threads:[~2006-03-16 11:50 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060315200956.4a9e2cb3.akpm@osdl.org>
2006-03-09 20:29 ` [PATCH] Document Linux's memory barriers [try #4] David Howells
2006-03-09 23:34   ` Paul Mackerras
2006-03-09 23:45     ` Michael Buesch
2006-03-09 23:56       ` Linus Torvalds
2006-03-10  0:07         ` Michael Buesch
2006-03-10  0:48     ` Alan Cox
2006-03-10  0:54       ` Paul Mackerras
2006-03-10  5:28   ` Nick Piggin
2006-03-10 15:19   ` David Howells
2006-03-11  0:01     ` Paul Mackerras
2006-03-12 17:15   ` Eric W. Biederman
2006-03-13 12:32   ` Sergei Organov
2006-03-14 20:31   ` David Howells
2006-03-14 21:11     ` linux-os (Dick Johnson)
2006-03-15  9:09       ` Sergei Organov
2006-03-15  9:04     ` Sergei Organov
2006-03-14 20:35   ` David Howells
2006-03-15  9:11     ` Sergei Organov
2006-03-14 21:26   ` David Howells
2006-03-14 21:48     ` Paul Mackerras
2006-03-14 23:59     ` David Howells
2006-03-15  0:20       ` Linus Torvalds
2006-03-15  1:25         ` Nick Piggin
2006-03-15  0:54       ` Paul Mackerras
2006-03-15  1:19       ` David Howells
2006-03-15  1:47         ` Linus Torvalds
2006-03-15 11:10   ` David Howells
2006-03-15 11:51     ` Nick Piggin
2006-03-15 13:47     ` David Howells
2006-03-15 23:21       ` Nick Piggin
2006-03-15 14:23   ` [PATCH] Document Linux's memory barriers [try #5] David Howells
2006-03-16 11:50     ` David Howells [this message]
2006-03-16 17:18       ` Linus Torvalds
2006-03-17  1:20         ` Nick Piggin
2006-03-16 23:17     ` Paul E. McKenney
2006-03-16 23:55       ` Linus Torvalds
2006-03-17  1:29         ` Paul E. McKenney
2006-03-17  5:32           ` Linus Torvalds
2006-03-17  6:23             ` Paul E. McKenney
2006-03-23 18:34     ` David Howells
2006-03-23 19:28       ` Linus Torvalds
2006-03-23 22:26       ` Paul E. McKenney
2006-03-28 22:25 Suzanne Wood
2006-03-29 17:54 ` David Howells
2006-03-29 20:51 Suzanne Wood
2006-03-30 20:18 ` David Howells
2006-03-31  0:55 Suzanne Wood
2006-03-31 14:51 ` David Howells
2006-03-31 16:16 Suzanne Wood

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=21253.1142509812@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=inux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@osdl.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

Powered by JetHome