Re: Non-reproducible AIO failure
От | Thomas Munro |
---|---|
Тема | Re: Non-reproducible AIO failure |
Дата | |
Msg-id | CA+hUKGJraDQyUq5BnjvU8OEH+SCvxmhCe2u98Ei9f1Q-HDLoZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Non-reproducible AIO failure (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Non-reproducible AIO failure
|
Список | pgsql-hackers |
On Tue, Aug 26, 2025 at 12:45 PM Andres Freund <andres@anarazel.de> wrote: > On 2025-08-25 10:43:21 +1200, Thomas Munro wrote: > > On Mon, Aug 25, 2025 at 6:11 AM Konstantin Knizhnik <knizhnik@garret.ru> wrote: > > > In theory even replacing bitfield with in should not > > > avoid race condition, because they are still shared the same cache line. > > > > I'm no expert in this stuff, but that's not my understanding of how it > > works. Plain stores to normal memory go into the store buffer and are > > eventually flushed to the memory hierarchy, but all modifications that reach > > the cache hierarchy have a consistent view of memory created by the cache > > coherency protocol (in ARM's case MOESI[1]): only one core can change a > > cache line at a time while it has exclusive access (with some optimisations, > > owner mode, snooping, etc but AFAIK that doesn't change the basic > > consistency). > > From what I understand that's not quite right - the whole point of the store > buffer is to avoid the latency hit of having to wait for cacheline > ownership. Instead the write is done into the store buffer, notably on a > granularity *smaller* than the cacheline (it has to be smaller, because we > don't have the contents of the cacheline). The reason that that is somewhat > OK from a coherency perspective is that this is done only for pure writes, not > read-modify-write operations. As the write overwrites the prior contents of > the memory, it is "ok" to do the write without waiting for cacheline ownership > ahead of time. *confused* Where's the contradiction?
В списке pgsql-hackers по дате отправления: