[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071016222921.GA29378@wotan.suse.de>
Date: Wed, 17 Oct 2007 00:29:21 +0200
From: Nick Piggin <npiggin@...e.de>
To: Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
Cc: Arjan van de Ven <arjan@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers)
On Tue, Oct 16, 2007 at 12:33:54PM +0200, Mikulas Patocka wrote:
>
>
> On Tue, 16 Oct 2007, Nick Piggin wrote:
>
> > > > The cpus also have an explicit set of instructions that deliberately do
> > > > unordered stores/loads, and s/lfence etc are mostly designed for those.
> > >
> > > I know about unordered stores (movnti & similar) --- they basically use
> > > write-combining method on memory that is normally write-back --- and they
> > > need sfence. But which one instruction does unordered load and needs
> > > lefence?
> >
> > Also, for non-wb memory. I don't think the Intel document referenced
> > says anything about this, but the AMD document says that loads can pass
> > loads (page 8, rule b).
> >
> > This is why our rmb() is still an lfence.
>
> 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.
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).
Doing that would lead to an unmaintainable mess. If drivers don't need rmb,
then they don't call it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists