Re: Spinlocks, yet again: analysis and proposed patches - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: Spinlocks, yet again: analysis and proposed patches
Date
Msg-id 014801c5ba39$2e96bca0$0f01a8c0@zaphod
Whole thread Raw
In response to Spinlocks, yet again: analysis and proposed patches  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_autovacuum settings not saved on dump
Next
From: Tom Lane
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches