From: Benjamin Herrenschmidt <bh40@calva.net>
To: linuxppc-dev@lists.linuxppc.org, Paul.Mackerras@cs.anu.edu.au
Subject: Re: Synchronization [was Re: The Magic Show: kernel_map() disappearing]
Date: Fri, 15 Jan 1999 09:50:05 +0100 [thread overview]
Message-ID: <19990115095005.011809@smtp.calvacom.fr> (raw)
On Fri, Jan 15, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
>I put a sync in for mb, rmb and wmb, which may be overkill. Certainly
>I think the eieio that Cort added after the sync for these things is
>unnecessary.
The sync may still be useful for subtle situations where the driver may
require the access to be physically done before doing something else,
like turning on interrupts on the CPU or setting a shared flag which can
be used by another CPU. Usually, those drivers are broken anyway because
of the PCI posting which is rarely handled (it was apparently also the
cause of the bogus interrupts, see the fix I posted previously).
I suggest keeping sync() in mb's for max. compatibility, and
batch-changing mb() and eieio() in current PPC drivers to iobarrier()
which, in turns, does eieio()
>> x86 and most other processors dont have the notion of a store barrier and
>> an i/o barrier beign different
>
>On x86, i/o accesses are strongly ordered already. On PPC the eieio
>instruction provides this sort of ordering (if you do it after each
>access). So I think eieio is right for iobarrier_*. Whether eieio
>would be sufficient for *mb(), or whether sync is needed, I'm not
>sure. Certainly sync should be sufficient.
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
next reply other threads:[~1999-01-15 8:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-15 8:50 Benjamin Herrenschmidt [this message]
[not found] <13980.23937.676502.388522@lassi.cygnus.co.uk>
[not found] ` <Pine.LNX.3.96.990113130000.3632F-100000@persephone.cs.nmt.edu>
1999-01-14 8:57 ` Synchronization [was Re: The Magic Show: kernel_map() disappearing] Jesper Skov
1999-01-14 9:55 ` Jes Sorensen
1999-01-14 16:25 ` luther sven
1999-01-14 13:27 ` Benjamin Herrenschmidt
1999-01-14 19:46 ` Douglas Godfrey
1999-01-14 20:52 ` Alan Cox
1999-01-14 21:53 ` Cort Dougan
1999-01-15 1:38 ` Alan Cox
1999-01-15 8:26 ` Jesper Skov
1999-01-15 1:57 ` Paul Mackerras
1999-01-15 8:40 ` Jes Sorensen
1999-01-15 16:10 ` Alan Cox
1999-01-15 19:28 ` Cort Dougan
1999-01-16 1:00 ` Douglas Godfrey
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=19990115095005.011809@smtp.calvacom.fr \
--to=bh40@calva.net \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=linuxppc-dev@lists.linuxppc.org \
/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;
as well as URLs for NNTP newsgroup(s).