Re: [PATCH] dtrace probes for memory manager

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: [PATCH] dtrace probes for memory manager
Дата
Msg-id 1258148287.1316.73.camel@localhost
обсуждение исходный текст
Ответ на Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > Attached patch contains new dtrace probes for memory management.
> 
> This is a bad idea and I want to reject it outright.  No ordinary user
> is really going to care about those details, and palloc is a
> sufficiently hot hot-spot that even the allegedly negligible overhead
> of an inactive dtrace probe is going to cost us.

I don't think that impact is too big here. User space DTrace probes are
implemented like function call. When probe is inactive call is replaced
by nop. Only what stay in code is arguments preparations.

there is asm code 32bit intel from palloc:

MemoryContextAlloc+0xae:        pushl  $0x0
MemoryContextAlloc+0xb0:        pushl  -0x8(%ebx)
MemoryContextAlloc+0xb3:        pushl  0xc(%ebp)
MemoryContextAlloc+0xb6:        movl   0x8(%ebp),%eax
MemoryContextAlloc+0xb9:        pushl  %eax
MemoryContextAlloc+0xba:        pushl  0x14(%eax)
MemoryContextAlloc+0xbd:        nop    
MemoryContextAlloc+0xbe:        nop    
MemoryContextAlloc+0xbf:        nop    
MemoryContextAlloc+0xc0:        nop    
MemoryContextAlloc+0xc1:        nop    
MemoryContextAlloc+0xc2:        addl   $0x20,%esp

You can see is that overhead depends on number of argument.  I used five
arguments now but two can be enough. Only dtrace script will be
complicated in some cases after that.

By my opinion if you compare whole palloc code path, Dtrace probes
overhead is minimal.
Zdenek




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCH] dtrace probes for memory manager
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Inspection of row types in pl/pgsql and pl/sql