From: Nick Piggin <npiggin@suse.de>
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Arjan van de Ven <arjan@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers)
Date: Wed, 17 Oct 2007 00:29:21 +0200 [thread overview]
Message-ID: <20071016222921.GA29378@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0710161221300.1315@artax.karlin.mff.cuni.cz>
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.
next prev parent reply other threads:[~2007-10-16 22:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 20:47 LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers) Mikulas Patocka
2007-10-15 21:37 ` Arjan van de Ven
2007-10-15 22:08 ` Mikulas Patocka
2007-10-16 0:11 ` H. Peter Anvin
2007-10-16 10:17 ` Mikulas Patocka
2007-10-16 15:42 ` LFENCE instruction H. Peter Anvin
2007-10-16 21:25 ` Mikulas Patocka
2007-10-16 0:22 ` LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers) Nick Piggin
2007-10-16 10:33 ` Mikulas Patocka
2007-10-16 22:29 ` Nick Piggin [this message]
2007-10-16 23:05 ` Mikulas Patocka
2007-10-16 23:21 ` Nick Piggin
2007-10-17 0:30 ` Mikulas Patocka
2007-10-17 12:24 ` Nick Piggin
2007-10-18 17:06 ` Mikulas Patocka
2007-10-17 5:51 ` Herbert Xu
2007-10-17 12:28 ` Nick Piggin
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=20071016222921.GA29378@wotan.suse.de \
--to=npiggin@suse.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikulas@artax.karlin.mff.cuni.cz \
/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