From: Hev <r@hev.cc>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org, Jiaxun Yang <jiaxun.yang@flygoat.com>,
Huacai Chen <chenhc@lemote.com>,
Paul Burton <paulburton@kernel.org>,
"Maciej W . Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] MIPS: Optional SYNC emulation
Date: Thu, 1 Oct 2020 15:45:52 +0800 [thread overview]
Message-ID: <CAHirt9i06fyHxinkurR-AA8rW2_Qm=UmAFgCPABsj=K9YADT2Q@mail.gmail.com> (raw)
In-Reply-To: <20200930111644.GA19903@alpha.franken.de>
Hello Thomas,
On Wed, Sep 30, 2020 at 8:48 PM Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
>
> On Fri, Aug 21, 2020 at 11:12:28AM +0800, Heiher wrote:
> > MIPS ISA defines several types of memory barrier, of which Type-0 (full barrier)
> > is required, and the others are optional. In some vendor implementation (such as
> > Loongson), all optional parts are implemented to emit an illegal instruction
> > exception. Here, emulate to full barrier to ensure the functional semantics.
> >
> > If an implementation does not support SYNC 0, it should also not support SMP, so
> > the `smp_mb()` is only a compilation barrier.
>
> I see your point, but isn't taking an exception already more than a
> compiler barrier ? Does the missing sync hurt in real life ?
As far as I known, the optional sync instruction has been used in user
space programs (such as firefox), and the illegal instruction
exception does not include the semantics of the memory barrier, so if
the optional sync instruction is not simulated, the memory access
order of these programs it may be different from the order in the
code.
About the compiler barrier, What if the hardware does not support SYNC
0? I think it does not support SMP, so smp_mb() is only a compiler
barrier and will not cause infinite recursion in the simulation.
Thank you
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
--
Best regards!
Hev
https://hev.cc
next prev parent reply other threads:[~2020-10-01 7:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 3:12 [PATCH] MIPS: Optional SYNC emulation Heiher
2020-09-30 11:16 ` Thomas Bogendoerfer
2020-10-01 7:45 ` Hev [this message]
2020-11-02 12:33 ` Maciej W. Rozycki
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='CAHirt9i06fyHxinkurR-AA8rW2_Qm=UmAFgCPABsj=K9YADT2Q@mail.gmail.com' \
--to=r@hev.cc \
--cc=chenhc@lemote.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-mips@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=paulburton@kernel.org \
--cc=tsbogend@alpha.franken.de \
/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).