Re: Some interesting results from tweaking spinlocks
От | Bruce Momjian |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 200201050530.g055U9N17817@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Some interesting results from tweaking spinlocks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Thanks. Looks good to me. --------------------------------------------------------------------------- Rod Taylor wrote: > 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 > > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: