Re: About gcc builtin atomics
On Tue, 26 Jun 2012 10:48:02 +0200, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Jun 26, 2012 at 10:26 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> > Geert Uytterhoeven dixit:
> >
> >>Even if they're fixed on ARAnyM, this doesn't fix the CAS problems on sev=
> eral
> >>instantations of real hardware....
> >
> > Right. That=E2=80=99s why we use the syscall always. OK.
> > (On Linux, but not on e.g. FreeMiNT.)
>
> FreeMiNT on which hardware?
>
> arch/m68k/Kconfig.cpu has:
>
> config RMW_INSNS
> bool "Use read-modify-write instructions"
> depends on ADVANCED
> ---help---
> This allows to use certain instructions that work with indivisible
> read-modify-write bus cycles. While this is faster than the
> workaround of disabling interrupts, it can conflict with DMA
> ( = direct memory access) on many Amiga systems, and it is also said
> to destabilize other machines. It is very likely that this will
> cause serious problems on any Amiga or Atari Medusa if set. The only
> configuration where it should work are 68030-based Ataris, where it
> apparently improves performance. But you've been warned! Unless you
> really know what you are doing, say N. Try Y only if you're quite
> adventurous.
I'd really like to see a more detailed description of the platform
issue. For starters,
1. "conflict with DMA" is very vague, what exactly are the symptoms?
2. "said to destabilize other machines" is also very vague, details?
3. are the 030s OK everywhere or just on Atari? what about 040s?
4. the option description says nothing about user-space; as the gcc
code is for shared variables in normal user-space program memory
rather than e.g. accessing control registers in MMIO space, it's
entirely possible that CAS is OK in user-space (at least as long
as mmap of MMIO space is disallowed)
OTOH, if CAS is provably unsafe in user-space for a sizeable portion
of the Linux/m68k HW base, then the kernel should IMO provide a
vsyscall page with at least CAS and DCAS/CAS64 entry points (doing
CAS or DCAS when possible, trapping otherwise), and possibly also
CAS.W and CAS.B entries.
/Mikael
Reply to: