| From: | "Min Xu (Hsu)" <xu(at)cs(dot)wisc(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Spinlocks, yet again: analysis and proposed patches |
| Date: | 2005-09-14 02:55:38 |
| Message-ID: | 20050914025533.GK5161@cs.wisc.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 13 Sep 2005 Tom Lane wrote :
> "Min Xu (Hsu)" <xu(at)cs(dot)wisc(dot)edu> writes:
> > ...If this were the case, perhaps first fetch the spin lock with read-only
> > permission should have helped.
>
> But the cmpb instruction in the 8.0 version of TAS would have done that,
> and I think we've already established that the cmpb is a loss on most
> machines (except maybe single-physical-CPU Xeons). I suggested in my
> other message that it might help to grab write permission on the cache
> line before actually trying to acquire the spin lock --- but I don't see
> how getting read-only permission first will help.
Yes, I agree. What I was trying to say was that if the second scenario
you hypothesize were true, i.e. fetching write-able line before actually
trying to acquire the spin lock would cause another processor to slow
down its execution inside the critical section, then fetching read-only
lines would have helped. As you said, however, experimental results
shows fetching read-only lines didn't help, which led me wonder whether the
second scenario your described was really happening.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-09-14 03:05:26 | Re: Spinlocks, yet again: analysis and proposed patches |
| Previous Message | Tom Lane | 2005-09-14 02:54:59 | Re: Spinlocks, yet again: analysis and proposed patches |