Re: Some interesting results from tweaking spinlocks
От | Rod Taylor |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 01a101c195a9$22029210$0202000a@jester обсуждение исходный текст |
Ответ на | Re: Some interesting results from tweaking spinlocks (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
The number of CPUs on a system should be fairly straight forward to find out. Distributed.net source code has some good examples. What I'm not sure of is how well this stuff reacts to CPUs being software disabled (Solaris has such a feature). ftp://ftp.distributed.net/pub/dcti/source/pub-20010416.tgz first function of client/common/cpucheck.cpp Each OS gets its own implementation, but they've got all the ones Postgresql uses covered off. -- Rod Taylor This message represents the official view of the voices in my head ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: <pgsql-hackers@postgresql.org> Sent: Friday, January 04, 2002 11:49 PM Subject: Re: [HACKERS] Some interesting results from tweaking spinlocks > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The difference is small, perhaps 15%. > > The thing that gets my attention is not that it's so small, it's that > it is so large. My expectation was that that code would hardly ever > be executed at all, and even less seldom (on a multiprocessor) need to > block via select(). How is it that *increasing* the delay interval > (which one might reasonably expect to simply waste cycles) can achieve > a 15% improvement in total throughput? That shouldn't be happening. > > > My feeling is that we may want to start configuring whether we are on > > a multi-cpu machine and handle thing differently. > > That would be more palatable if there were some portable way of > detecting it. But maybe we'll be forced into an "is_smp" GUC switch. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
В списке pgsql-hackers по дате отправления: