MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Date: Sat, 21 Mar 2009 19:02:46 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <603c8f070903201745m575642f5s539e1a374ce4ce9f@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>,
	Scott Carey <scott@richrelevance.com>, Greg Smith <gsmith@gregsmith.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49C57216.1050205@sun.com>
References: <603c8f070903191349p5e8fb00as2816581d584fcefd@mail.gmail.com>
	<BDFBB77C9E07BE4A984DAAE981D19F961AEE7AFBB5@EXVMBX018-1.exch018.msoutlookonline.net>
	<20090320154601.GC8313@alvh.no-ip.org>
	<20090320215813.GR8313@alvh.no-ip.org>
	<20090320220513.GS8313@alvh.no-ip.org> <49C42921.8050508@sun.com>
	<603c8f070903201745m575642f5s539e1a374ce4ce9f@mail.gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)


Robert Haas wrote:
> On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah <J.K.Shah@sun.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