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  (dg@illustra.com (David Gould))
Список 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 по дате отправления:

Предыдущее
От: dg@illustra.com (David Gould)
Дата:
Сообщение: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contention
Следующее
От: Byron Nikolaidis
Дата:
Сообщение: Timestamp field