Re: can we optimize STACK_DEPTH_SLOP

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: can we optimize STACK_DEPTH_SLOP
Дата
Msg-id CAM-w4HMfizBUz-Mm700-14OffBLtfEpLyAfgc2CP5cw6WvWicA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: can we optimize STACK_DEPTH_SLOP  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: can we optimize STACK_DEPTH_SLOP  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jul 8, 2016 at 3:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm, after reading the man page I don't quite see how that would help?
> You'd have to already know the mapped stack address range in order to
> call the function without getting ENOMEM.


I had assumed unmapped pages would just return a 0 in the bitmap. I
suppose you could still do it by just probing one page at a time until
you find an unmapped page. In a way that's better since you can count
stack pages even if they're paged out.


Fwiw here's the pmap info from burbot (Linux Sparc64):
136      48      48 rw---    [ stack ]
136      48      48 rw---    [ stack ]
136      48      48 rw---    [ stack ]
136      48      48 rw---    [ stack ]
136      56      56 rw---    [ stack ]
136      80      80 rw---    [ stack ]
136      96      96 rw---    [ stack ]
136     112     112 rw---    [ stack ]
136     112     112 rw---    [ stack ]
576     576     576 rw---    [ stack ]
2056    2056    2056 rw---    [ stack ]

I'm actually a bit confused how to interpret these numbers. This
appears to be an 8kB pagesize architecture so is that 576*8kB or over
5MB of stack for the regexp test? But we don't know if there are any
check_stack_depth calls in that call tree?

-- 
greg



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Showing parallel status in \df+
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: MVCC overheads