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

From Greg Stark
Subject Re: can we optimize STACK_DEPTH_SLOP
Date
Msg-id CAM-w4HN8-ZRj4MvVT+ex5VUMzHAFumGUk914QkEyu4x9eSXTtw@mail.gmail.com
Whole thread Raw
In response to Re: can we optimize STACK_DEPTH_SLOP  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: can we optimize STACK_DEPTH_SLOP  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jul 8, 2016 at 4:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Searching for info on ia64 turned up this interesting thread:

https://www.postgresql.org/message-id/21563.1289064886%40sss.pgh.pa.us

From that discussion it seems we should probably run these tests with
-O0 because the stack usage can be substantially higher without
optimizations. And it doesn't sound like ia64 uses much more *normal*
stack, just that there's the additional register stack.

It might not be unreasonable to commit the pmap hack, gather the data
from the build farm then later add an #ifdef around it. (or just make
it #ifdef USE_ASSERTIONS which I assume most build farm members are
running with anyways).

Alternatively it wouldn't be very hard to use mincore(2) to implement
it natively. I believe mincore is nonstandard but present in Linux and
BSD.


-- 
greg



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Reviewing freeze map code
Next
From: Tom Lane
Date:
Subject: Re: can we optimize STACK_DEPTH_SLOP