From: David Howells <dhowells@redhat.com>
In-Reply-To: <20060315200956.4a9e2cb3.akpm@osdl.org> 
References: <20060315200956.4a9e2cb3.akpm@osdl.org>  <16835.1141936162@warthog.cambridge.redhat.com> <18351.1142432599@warthog.cambridge.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
Message-ID: <21253.1142509812@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1914
Lines: 42

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/