Re: spinlocks on HP-UX
От | Robert Haas |
---|---|
Тема | Re: spinlocks on HP-UX |
Дата | |
Msg-id | CA+Tgmoa4Eh0_7JBevcLhN8ETYoL8uzx21JsVd2dURCd=Q=K0fA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: spinlocks on HP-UX (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: spinlocks on HP-UX
|
Список | pgsql-hackers |
On Sun, Aug 28, 2011 at 7:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > So this pretty well confirms Robert's results, in particular that all of > the win from an unlocked test comes from using it in the delay loop. > Given the lack of evidence that a general change in TAS() is beneficial, > I'm inclined to vote against it, on the grounds that the extra test is > surely a loss at some level when there is not contention. > (IOW, +1 for inventing a second macro to use in the delay loop only.) Beautiful. Got a naming preference for that second macro? I suggested TAS_SPIN() because it's what you use when you spin, as opposed to what you use in the uncontended case, but I'm not attached to that. > We ought to do similar tests on other architectures. I found some > lots-o-processors x86_64 machines at Red Hat, but they don't seem to > own any PPC systems with more than 8 processors. Anybody have big > iron with other non-Intel chips? Aside from PPC, it would probably be worth testing SPARC and ARM if we can find machines. Anything else is probably too old or too marginal to get excited about. AFAIK these effects don't manifest with <32 cores, so I suspect that a lot of what's in s_lock.h is irrelevant just because many of those architectures are too old to exist in 32-core versions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: