From: | "Michael Paesold" <mpaesold(at)gmx(dot)at> |
---|---|
To: | "Marko Kreen" <marko(at)l-t(dot)ee>, "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-15 21:05:19 |
Message-ID: | 014801c5ba39$2e96bca0$0f01a8c0@zaphod |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I guess what this means is that there's no real problem with losing the
> cache line while manipulating the LWLock, which is what the patch was
> intended to prevent. Instead, we're paying for swapping two cache lines
> (the spinlock and the LWLock) across processors instead of just one line.
> But that should at worst be a 2x inflation of the time previously spent
> in LWLockAcquire/Release, which is surely not yet all of the application
> ;-). Why the heck is this so bad? Should we expect that apparently
> minor changes in shared data structures might be costing equivalently
> huge penalties in SMP performance elsewhere?
>
> Unfortunately I don't have root on the Opteron and can't run oprofile.
> But I'd really like to see some oprofile stats from these two cases
> so we can figure out what in the world is going on here. Can anyone
> help?
I will try the patch here and see if it gives the same result. If so I could
try to run with oprofile if you can give me a quick start.
Best Regards,
Michael Paesold
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-15 21:49:03 | Re: Spinlocks, yet again: analysis and proposed patches |
Previous Message | Tom Lane | 2005-09-15 20:00:11 | Re: pg_autovacuum settings not saved on dump |