Re: Spinlocks, yet again: analysis and proposed patches
От | Michael Paesold |
---|---|
Тема | Re: Spinlocks, yet again: analysis and proposed patches |
Дата | |
Msg-id | 014801c5ba39$2e96bca0$0f01a8c0@zaphod обсуждение исходный текст |
Ответ на | Spinlocks, yet again: analysis and proposed patches (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: