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
|
Список | 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 по дате отправления: