On Tue, Jun 28, 2016 at 08:48:28 -0700, Richard Henderson wrote:
> On 06/28/2016 01:45 AM, Lluís Vilanova wrote:
> >Emilio G Cota writes:
> >[...]
> >>- What to do when atomic ops are used on something other than RAM?
> >> Should we have a "slow path" that is not atomic for these cases, or
> >> it's OK to assume code is bogus? For now, I just wrote XXX.
> >[...]
> >
> >You mean, for example, on I/O space? In these cases, it depends on the
> >specific
> >device you're accessing and the interconnect used to access it.
Yes, exactly. Anything non-cacheable, really.
> >TL;DR: In some cases, it makes sense to support atomics outside RAM.
> >
> >For example, PCIe has support for expressing atomic operations in its
> >messages
> >(I'm sure other interconnects do too). But in the end it depends on whether
> >the
> >device supports them (I'm not sure if the device can reject atomics and
> >produce
> >an error to whomever tried to do the atomic access, or if they are simply
> >ignored).
But these messages wouldn't be generated as a result of calling cmpxchg
on the memory-mapped I/O address, right?
> Indeed. Thankfully, that's rare. Many cpus explicitly say that the atomic
> ops can't be used on non-cachable memory, since they use the cache coherency
> protocol to implement the atomicity.
>
> That said, I can imagine that this probably works on x86, and supporting
> this is going to require a stop-the-world kind of emulation.
I'm assuming virtually all device drivers serialize accesses so that
"read-modify-write" cycles can be implemented as a read+write
on the bus. I have written quite a few drivers and it never occurred
to me to write cmpxchg or equivalent on an I/O address.
That said, for a non-RFC submission of this patchset, what should
we do? Just abort() for now, or do a non-atomic cycle? Stop-the-world
isn't available yet, and I wouldn't want to wait for it--this is not
a huge deal-breaker for most code out there, I think.
Thanks,
Emilio
