| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
| Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, jwbaker(at)acm(dot)org |
| Subject: | Re: LWLock contention: I think I understand the problem |
| Date: | 2001-12-30 18:04:29 |
| Message-ID: | 464.1009735469@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-odbc |
I have thought of a further refinement to the patch I produced
yesterday. Assume that there are multiple waiters blocked on (eg)
BufMgrLock. After we release the first one, we want the currently
running process to be able to continue acquiring and releasing the lock
for as long as its time quantum holds out. But in the patch as given,
each acquire/release cycle releases another waiter. This is probably
not good.
Attached is a modification that prevents additional waiters from being
released until the first releasee has a chance to run and acquire the
lock. Would you try this and see if it's better or not in your test
cases? It doesn't seem to help on a single CPU, but maybe on multiple
CPUs it'll make a difference.
To try to make things simple, I've attached the mod in two forms:
as a diff from current CVS, and as a diff from the previous patch.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| unknown_filename | text/plain | 9.3 KB |
| unknown_filename | text/plain | 3.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-12-30 18:46:05 | Are we accepting cancel interrupts too often? |
| Previous Message | Tom Lane | 2001-12-30 16:52:58 | Re: LWLock contention: I think I understand the problem |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-12-30 23:44:13 | My email is fixed |
| Previous Message | Tom Lane | 2001-12-30 16:52:58 | Re: LWLock contention: I think I understand the problem |