[PATCH] x86: Optimize atomic_compare_and_exchange_[val|bool]_acq [BZ #28537]

Oleh Derevenko oleh.derevenko@gmail.com
Wed Nov 3 17:55:35 GMT 2021


Arjan,

> eh I am not sure I understand what you say since cmpxchg uses the exact same
> cache protocol/etc to do its read...
Well, if you are sure... I did not have that information.

The last question if you permit.
What, as to your opinion, are the reasons they did it in the hardware
implementation? This thing, I mean:
> The full compare and swap will grab the cache line exclusive and cause excessive cache line bouncing.
Why was not this optimization initially implemented in the CPU?

Well, I guess I can explain it myself. Because in the success cases
these extra checks would add to execution time. And cmpcxhg can be
used for many purposes — not only for polling from four threads in
parallel.


On Wed, Nov 3, 2021 at 7:30 PM Arjan van de Ven <arjan@linux.intel.com> wrote:
>
> On 11/3/2021 10:26 AM, Oleh Derevenko wrote:
> > Arjan
> >
> >> What the patch does is check non-atomic first if the actual atomic operation has
> > a chance of working. if it has a chance, the actual normal atomic
> > operation is done as
> > before. But if non-atomic read already tells you the cmpxchg has no
> > chance to succeed, it errors
> > out early.
> >
> > The idea of atomic function is that they are intended to work fairly
> > with any type of memory. In your case, the speculative reads for a
> > cached device memory may result in cache access only and will prevent
> > fetching memory updates from the device, thus making the reading
> > thread "see" the change later than it could.
>
>
> eh I am not sure I understand what you say since cmpxchg uses the exact same
> cache protocol/etc to do its read...  it won't go to device memory either if
> the cache line is anywhere in the cache hierarchy (including core-to-core transfers
> in case another core has it in their caches)
>
>
> (and cmpxchg on MMIO space has very very interesting and unexpected behavior. If folks remember
> the "linux torches your e1000 eeprom" bug from some years ago, it came from that)



-- 

Oleh Derevenko

-- Skype with underscore


More information about the Libc-alpha mailing list