Re: Proposal of tunable fix for scalability of 8.4

Robert Haas wrote:
> On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah <J(dot)K(dot)Shah(at)sun(dot)com> wrote:
>
>> Alvaro Herrera wrote:
>>
>>>> So Simon's correct.
>>>>
>>> And perhaps this explains why Jignesh is measuring an improvement on his
>>> benchmark. Perhaps an useful experiment would be to turn this behavior
>>> off and compare performance. This lack of measurement is probably the
>>> cause that the suggested patch to fix it was never applied.
>>>
>>> The patch is here
>>> http://archives.postgresql.org//pgsql-hackers/2004-11/msg00935.php
>>>
>> One of the reasons why my patch helps is it keeps this check intact but
>> allows other exclusive Wake up.. Now what PostgreSQL calls "Wakes" is in
>> reality just makes a variable indicating wake up and not really signalling a
>> process to wake up. This is a key point to note. So when the process wanting
>> the exclusive fights the OS Scheduling policy to finally get time on the CPU
>> then it check the value to see if it is allowed to wake up and potentially
>>
>
> I'm confused. Is a process waiting for an LWLock is in a runnable
> state? I thought we went to sleep on a semaphore.
>
> ...Robert
>
>
If you check the code
http://doxygen.postgresql.org/lwlock_8c-source.html#l00451

Semaphore lock can wake up but then it needs to confirm !proc->lwWaiting
which can be TRUE if you have not been "Waked up"
then it increase the extraWaits count and go back to PGSemaphoreLock
.. What my patch gives the flexibility with sequential X wakeups that it
can still exit and check for getting the exclusive lock and if not add
back to the queue. My theory is when it is already on CPU running makes
sense to check for the lock if another exclusive is running since the
chances are that it has completed within few cycles is very high.. and
the improvement that I see leads to that inference. Otherwise if
lwWaiting is TRUE then it does not even check if the lock is available
or not and just goes back and waits for the next chance.. This is the
part that gets the benefit of my patch.

-Jignesh

--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql