Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935724AbXJPXF3 (ORCPT ); Tue, 16 Oct 2007 19:05:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755668AbXJPXFT (ORCPT ); Tue, 16 Oct 2007 19:05:19 -0400 Received: from artax.karlin.mff.cuni.cz ([195.113.31.125]:40462 "EHLO artax.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752789AbXJPXFR (ORCPT ); Tue, 16 Oct 2007 19:05:17 -0400 Date: Wed, 17 Oct 2007 01:05:16 +0200 (CEST) From: Mikulas Patocka To: Nick Piggin cc: Arjan van de Ven , Linux Kernel Mailing List Subject: Re: LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers) In-Reply-To: <20071016222921.GA29378@wotan.suse.de> Message-ID: References: <20071015143732.01d99af8@laptopd505.fenrus.org> <20071016002229.GA5851@wotan.suse.de> <20071016222921.GA29378@wotan.suse.de> X-Personality-Disorder: Schizoid 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: 1680 Lines: 38 > > I see, AMD says that WC memory loads can be out-of-order. > > > > There is very little usability to it --- framebuffer and AGP aperture is > > the only piece of memory that is WC and no kernel structures are placed > > there, so it is possible to remove that lfence. > > No. In Linux kernel, rmb() means that all previous loads, including to > any IO regions, will be executed before any subsequent load. You already must not place any data structures into WC memory --- for example, spinlocks wouldn't work there. wmb() also won't work on WC memory, because it assumes that writes are ordered. > How can you possibly get rid of lfence from there just because you may > happen to *know* that it isn't used (btw. the IO serialisation isn't for > kernel data structures, it is for actual IO operations, generally). IO regions are in uncached memory, and x86 already serializes it fine. It flushes any write buffers on access to uncached memory. (BTW. what is the general portable rule for serializing writel() and readl()? On x86 they are serialized in hardware, but what on other archs?) > Doing that would lead to an unmaintainable mess. If drivers don't need rmb, > then they don't call it. If wmb() doesn't currently work on write-combining memory, why should rmb() work there? The purpose of rmb() is to enforce ordering on architectures that don't force it in hardware --- that is not the case of x86. Mikulas - 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/