Message-ID: <456DA476.4000606@janestcapital.com>
Date: Wed, 29 Nov 2006 10:17:10 -0500
From: Brian Hurt <bhurt@janestcapital.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: Mark Lewis <mark.lewis@mir3.com>
CC: pgsql-performance@postgresql.org
Subject: Re: RES: Priority to a mission critical transaction
References: <4939.1164740825@sss.pgh.pa.us>	
	<200611282344.kASNijt09203@momjian.us>	
	<456CE066.50803@cheapcomplexdevices.com>	
	<456D8A65.3080400@janestcapital.com>
	<1164812624.9690.500.camel@archimedes>
In-Reply-To: <1164812624.9690.500.camel@archimedes>
Content-Type: multipart/alternative;
	boundary="------------040203070606010201070205"

This is a multi-part message in MIME format.
--------------040203070606010201070205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark Lewis wrote:

>On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
>...
>  
>
>>I have the same question.  I've done some embedded real-time 
>>programming, so my innate reaction to priority inversions is that 
>>they're evil.  But, especially given priority inheritance, is there any 
>>situation where priority inversion provides *worse* performance than 
>>running everything at the same priority?  I can easily come up with 
>>situations where it devolves to that case- where all processes get 
>>promoted to the same high priority.  But I can't think of one where 
>>using priorities makes things worse, and I can think of plenty where it 
>>makes things better.
>>    
>>
>...
>
>It can make things worse when there are at least 3 priority levels
>involved.  The canonical sequence looks as follows:
>
>LOW:  Aquire a lock
>MED:  Start a long-running batch job that hogs CPU
>HIGH: Wait on lock held by LOW task
>
>at this point, the HIGH task can't run until the LOW task releases its
>lock. but the LOW task can't run to completion and release its lock
>until the MED job completes.
>
>  
>
>(random musing): I wonder if PG could efficiently be made to temporarily
>raise the priority of any task holding a lock that a high priority task
>waits on.  I guess that would just make it so that instead of HIGH tasks
>being effectively reduced to LOW, then LOW tasks could be promoted to
>HIGH.
>
>  
>

I thought that was what priority inheritance did- once HIGH blocks on a 
lock held by LOW, LOW gets it's priority raised to that of HIGH.  Then 
LOW takes precedence over MED.  If LOW blocks on a lock held by MED when 
it has the same priority of HIGH, MED gets it's priority raised to 
HIGH.  Note that now all three processes are running with HIGH priority- 
but is this any different from the default case of running them as the 
same priority?  This is what I was talking about when I said I could 
imagine priority inheritance "devolving" to the single priority case.

Of course, this is a little tricky to implement.  I haven't looked at 
how difficult it'd be within Postgres.

Brian


--------------040203070606010201070205
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mark Lewis wrote:<br>
<blockquote cite="mid1164812624.9690.500.camel@archimedes" type="cite">
  <pre wrap="">On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:
...
  </pre>
  <blockquote type="cite">
    <pre wrap="">I have the same question.  I've done some embedded real-time 
programming, so my innate reaction to priority inversions is that 
they're evil.  But, especially given priority inheritance, is there any 
situation where priority inversion provides *worse* performance than 
running everything at the same priority?  I can easily come up with 
situations where it devolves to that case- where all processes get 
promoted to the same high priority.  But I can't think of one where 
using priorities makes things worse, and I can think of plenty where it 
makes things better.
    </pre>
  </blockquote>
  <pre wrap=""><!---->...

It can make things worse when there are at least 3 priority levels
involved.  The canonical sequence looks as follows:

LOW:  Aquire a lock
MED:  Start a long-running batch job that hogs CPU
HIGH: Wait on lock held by LOW task

at this point, the HIGH task can't run until the LOW task releases its
lock. but the LOW task can't run to completion and release its lock
until the MED job completes.

  </pre>
</blockquote>
<blockquote cite="mid1164812624.9690.500.camel@archimedes" type="cite">
  <pre wrap="">(random musing): I wonder if PG could efficiently be made to temporarily
raise the priority of any task holding a lock that a high priority task
waits on.  I guess that would just make it so that instead of HIGH tasks
being effectively reduced to LOW, then LOW tasks could be promoted to
HIGH.

  </pre>
</blockquote>
<br>
I thought that was what priority inheritance did- once HIGH blocks on a
lock held by LOW, LOW gets it's priority raised to that of HIGH.&nbsp; Then
LOW takes precedence over MED.&nbsp; If LOW blocks on a lock held by MED
when it has the same priority of HIGH, MED gets it's priority raised to
HIGH.&nbsp; Note that now all three processes are running with HIGH
priority- but is this any different from the default case of running
them as the same priority?&nbsp; This is what I was talking about when I
said I could imagine priority inheritance "devolving" to the single
priority case.<br>
<br>
Of course, this is a little tricky to implement.&nbsp; I haven't looked at
how difficult it'd be within Postgres.<br>
<br>
Brian<br>
<br>
</body>
</html>

--------------040203070606010201070205--