Re: can we optimize STACK_DEPTH_SLOP - Mailing list pgsql-hackers

I wrote:
> Based on these numbers, I'd have no fear of reducing STACK_DEPTH_SLOP
> to 256KB on x86_64.  It would sure be good to check things on some
> other architectures, though ...

I went to the work of doing the same test on a PPC Mac:
182 Stack                   [   8192K/     40K] 25 Stack                   [   8192K/     48K]  2 Stack
 [   8192K/     56K] 11 Stack                   [   8192K/     60K]  5 Stack                   [   8192K/     64K]  2
Stack                  [   8192K/    108K]  1 Stack                   [   8192K/    576K]  1 Stack                   [
8192K/   2056K]
 

The last number here is "resident pages", not "dirty pages", because
this older version of OS X doesn't provide the latter.  Still, the
numbers seem to track pretty well with the ones I got on x86_64.
Which is a bit odd when you think about it: a 32-bit machine ought
to consume less stack space because pointers are narrower.

Also on my old HPPA dinosaur:
 40  addr 0x7b03a000, length 8, physical pages 8, type STACK166  addr 0x7b03a000, length 10, physical pages 9, type
STACK26  addr 0x7b03a000, length 12, physical pages 11, type STACK 16  addr 0x7b03a000, length 14, physical pages 13,
typeSTACK  1  addr 0x7b03a000, length 15, physical pages 13, type STACK  1  addr 0x7b03a000, length 16, physical pages
15,type STACK  2  addr 0x7b03a000, length 28, physical pages 27, type STACK  1  addr 0x7b03a000, length 190, physical
pages190, type STACK  1  addr 0x7b03a000, length 514, physical pages 514, type STACK
 

As best I can tell, "length" is the nominal virtual space for the stack,
and "physical pages" is the actually allocated/resident space, both
measured in 4K pages.  So that again matches pretty well, although the
stack-efficiency of the recursive regex functions seems to get worse with
each new case I look at.

However ... the thread here
https://www.postgresql.org/message-id/flat/21563.1289064886%40sss.pgh.pa.us
says that depending on your choice of compiler and optimization level,
IA64 can be 4x to 5x worse for stack space than x86_64, even after
spotting it double the memory allocation to handle its two separate
stacks.  I don't currently have access to an IA64 machine to check.

Based on what I'm seeing so far, really 100K ought to be more than plenty
of slop for most architectures, but I'm afraid to go there for IA64.

Also, there might be some more places like tzload() that are putting
unreasonably large variables on the stack, but that the regression tests
don't exercise (I've not tested anything replication-related, for
example).

Bottom line: I propose that we keep STACK_DEPTH_SLOP at 512K for IA64
but reduce it to 256K for everything else.
        regards, tom lane