From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Sat, 21 Mar 2009 19:02:46 -0400
Message-ID: <49C57216.1050205@sun.com> (raw)
In-Reply-To: <603c8f070903201745m575642f5s539e1a374ce4ce9f@mail.gmail.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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, robertmhaas@gmail.com, alvherre@commandprompt.com, scott@richrelevance.com, gsmith@gregsmith.com, Kevin.Grittner@wicourts.gov
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <49C57216.1050205@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox