Re: Non-reproducible AIO failure
От | Andres Freund |
---|---|
Тема | Re: Non-reproducible AIO failure |
Дата | |
Msg-id | lqei26qqnshklqwd3sa6y2tn3ksyqwywbqidbr5gsphbes4633@yq5eejhtmfbh обсуждение исходный текст |
Ответ на | Re: Non-reproducible AIO failure (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Non-reproducible AIO failure
|
Список | pgsql-hackers |
Hi, 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: