Re: pgsql: Reduce the number of semaphores used under --disable-spinlocks.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Reduce the number of semaphores used under --disable-spinlocks. |
Дата | |
Msg-id | 20140618193243.GW3115@awork2.anarazel.de обсуждение исходный текст |
Ответ на | pgsql: Reduce the number of semaphores used under --disable-spinlocks. (Robert Haas <rhaas@postgresql.org>) |
Список | pgsql-committers |
Hi, On 2014-01-08 23:58:16 +0000, Robert Haas wrote: > Reduce the number of semaphores used under --disable-spinlocks. > > Instead of allocating a semaphore from the operating system for every > spinlock, allocate a fixed number of semaphores (by default, 1024) > from the operating system and multiplex all the spinlocks that get > created onto them. This could self-deadlock if a process attempted > to acquire more than one spinlock at a time, but since processes > aren't supposed to execute anything other than short stretches of > straight-line code while holding a spinlock, that shouldn't happen. > > One motivation for this change is that, with the introduction of > dynamic shared memory, it may be desirable to create spinlocks that > last for less than the lifetime of the server. Without this change, > attempting to use such facilities under --disable-spinlocks would > quickly exhaust any supply of available semaphores. Quite apart > from that, it's desirable to contain the quantity of semaphores > needed to run the server simply on convenience grounds, since using > too many may make it harder to get PostgreSQL running on a new > platform, which is mostly the point of --disable-spinlocks in the > first place. I'm looking at the way you did this in the context of the atomics patch. Won't: s_init_lock_sema(volatile slock_t *lock) { static int counter = 0; *lock = (++counter) % NUM_SPINLOCK_SEMAPHORES; } lead to bad results if spinlocks are intialized after startup? Essentially mapping new spinlocks to the same semaphore? That's a restriction I can live with, especially as this is only for super old platforms. But it might be worth mentioning somewhere? I've essentially reeimplemented that kind of logic in the atomics patch. Looking to get rid of the duplication... There I used something like slot = ((uintptr_t) addr_of_atomic >> (sizeof(void*) + 5)) % NUM_LOCKS but I think your method is actually better because it allows to place spinlocks/atomics to be placed in dsm segments placed at different location in individual processes. My current plan to get rid of the duplication is to simply embed the spinlock inside the atomic variable instead of having a separate array of spinlocks protecting atomic variables. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-committers по дате отправления: