Re: Add spin_delay() implementation for Arm in s_lock.h
От | Tom Lane |
---|---|
Тема | Re: Add spin_delay() implementation for Arm in s_lock.h |
Дата | |
Msg-id | 1271756.1641523197@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add spin_delay() implementation for Arm in s_lock.h (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Add spin_delay() implementation for Arm in s_lock.h
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: >> I landed on the idea of adding some intentional spinlock >> contention to src/test/modules/test_shm_mq, which is a prefab test >> framework for passing data among multiple worker processes. The >> attached quick-hack patch makes it grab and release a spinlock once >> per passed message. > I wonder if this will show the full set of spinlock contention issues - isn't > this only causing contention for one spinlock between two processes? I don't think so -- the point of using the "pipelined" variant is that messages are passing between all N worker processes concurrently. (With the proposed test, I see N processes all pinning their CPUs; if I use the non-pipelined API, they are busy but nowhere near 100%.) It is just one spinlock, true, but I think the point is to gauge what happens with N processes all contending for the same lock. We could add some more complexity to use multiple locks, but does that really add anything but complexity? regards, tom lane
В списке pgsql-hackers по дате отправления: