From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: can we optimize STACK_DEPTH_SLOP |
Date: | 2016-07-08 19:21:51 |
Message-ID: | CAM-w4HMfizBUz-Mm700-14OffBLtfEpLyAfgc2CP5cw6WvWicA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 8, 2016 at 3:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-07-08 19:44:22 | Re: MVCC overheads |
Previous Message | Pavel Stehule | 2016-07-08 19:02:02 | Re: Showing parallel status in \df+ |