Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contention
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contention |
Дата | |
Msg-id | 199806101650.MAA27806@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Try again: S_LOCK reduced contention (dg@illustra.com (David Gould)) |
Ответы |
Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contention
|
Список | pgsql-hackers |
> Most of the original tas() __asm__() implementations are GCC specific. This > includes all the Linux platforms except PPC, all the *BSD platforms, even the > VAX. GCC is also fairly commonly used even on the commercial OSes. > > As far as I can tell, the only C coded platforms that are not GCC specific > are SCO i386 and SunOS/Solaris on Sun3 and Sparc. The other non-GCC platforms > have external tas.s function implementations (HP), or have system specific > calls (AIX, OSF, SGI, Nextstep). That s_lock.h file is a hornets nest of portability problems. I really don't want to have multiple functions/macros for different CPU's if I can help it. I don't even want to mix functions/macros for the same function name if I can help it. I also do not want to start playing around with isGNU/isnotGNU in a file that is already complex. Macros work and we already have tons of them, we don't use inline anywhere else, and the actual locks are 80% asm code anyway, so it looks the same whether it is in a macro or an inline function. I have made them macros before for this file, so I can do it again quite easily. As for the benefits, well, when I see lots of calls to a function, and I try and eliminate the calls if it is reasonable. In many places, the call handling is actually more instructions than the inlining. I look at the measured performance change vs. the executable size increase and make a decision. With something like s_lock, it just seems normal to make it a macro. > Finally, the difference between a tas() function implementation and the best > possible inline implementation appears to be only 0.06 microseconds on a P133. > This will add 0.0003 seconds to startup. On SCO only. On Sparc this is a leaf > call and possibly even cheaper. No other platforms are affected. > > Remember also that I am adding two features that previously did not exist, > backoff, and stuck lock detection. Yes, and good improvements. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: