From: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
---|---|
To: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: LWLock contention: I think I understand the problem |
Date: | 2001-12-29 20:23:20 |
Message-ID: | Pine.LNX.4.33.0112291220230.30167-100000@windmill.gghcwest.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-odbc |
On Sat, 29 Dec 2001, Tom Lane wrote:
> After some further experimentation, I believe I understand the reason for
> the reports we've had of 7.2 producing heavy context-swap activity where
> 7.1 didn't. Here is an extract from tracing lwlock activity for one
> backend in a pgbench run:
...
> It would seem, therefore, that lwlock.c's behavior of immediately
> granting the lock to released waiters is not such a good idea after all.
> Perhaps we should release waiters but NOT grant them the lock; when they
> get to run, they have to loop back, try to get the lock, and possibly go
> back to sleep if they fail. This apparent waste of cycles is actually
> beneficial because it saves context swaps overall.
Sounds reasonable enough, but there seems to be a possibility of a process
starving. For example, if A releases the lock, B and C wake up, B gets
the lock. Then B releases the lock, A and C wake, and A gets the lock
back. C gets CPU time but never gets the lock.
BTW I am not on this list.
-jwb
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-29 20:49:33 | Re: LWLock contention: I think I understand the problem |
Previous Message | Pavlo Baron | 2001-12-29 20:12:09 | Re: TODO question |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-29 20:49:33 | Re: LWLock contention: I think I understand the problem |
Previous Message | Bruce Momjian | 2001-12-29 20:07:47 | Re: LWLock contention: I think I understand the problem |