Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932420AbWCPRSi (ORCPT ); Thu, 16 Mar 2006 12:18:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752435AbWCPRSi (ORCPT ); Thu, 16 Mar 2006 12:18:38 -0500 Received: from smtp.osdl.org ([65.172.181.4]:16352 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1752436AbWCPRSh (ORCPT ); Thu, 16 Mar 2006 12:18:37 -0500 Date: Thu, 16 Mar 2006 09:18:26 -0800 (PST) From: Linus Torvalds To: David Howells cc: Andrew Morton , nickpiggin@yahoo.com.au, inux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Document Linux's memory barriers [try #5] In-Reply-To: <21253.1142509812@warthog.cambridge.redhat.com> Message-ID: References: <20060315200956.4a9e2cb3.akpm@osdl.org> <16835.1141936162@warthog.cambridge.redhat.com> <18351.1142432599@warthog.cambridge.redhat.com> <21253.1142509812@warthog.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1570 Lines: 32 On Thu, 16 Mar 2006, David Howells wrote: > > 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:-/ Well, the argument I have against mentioning caches is that cache coherency order is _not_ the only thing that is relevant. As already mentioned, data speculation can cause exactly the same "non-causal" effect as cache update ordering, so from a _conceptual_ standpoint, the cache is really just one implementation detail in the much bigger picture of buffering and speculative work re-ordering operations... So it might be a good idea to first explain the memory barriers in a more abstract sense without talking about what exactly goes on, and then have the section that gives _examples_ of what the CPU actually is doing that causes these barriers to be needed. And make it clear that the examples are just that - examples. Linus - 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/