Bill Allombert on Mon, 03 Oct 2016 20:21:57 +0200


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Use PROT_NONE for unused virtual stack memory


On Mon, Oct 03, 2016 at 05:04:53PM +0200, Jeroen Demeyer wrote:
> On 2016-09-29 17:46, Bill Allombert wrote:
> >Do you have some framework to test this ?
> 
> Not really because it depends a lot on the OS. In order to properly test
> this, you need a Linux system with vm.overcommit = 2. So you need
> 
> # echo 2 >/proc/sys/vm/overcommit_memory

What linux kernel version did you test ?  And how did you test it ?

> >>The idea is to use PROT_NONE for the unused part of the PARI stack (between
> >>vbot and bot). Memory mmap()ed with PROT_NONE is not committed: it does not
> >>count against the available physical/swap memory available for the system.
> >
> >Do you have some relevant documentation for this behaviour ?
> 
> No. As far as I know, this is undocumented. 

This is problematic... I wrote this code following the POSIX standard.
The code is not meant to be linux specific.

However I have no issue with using map(,PROT_NONE) and remapping to
map(,PROT_WRITE|PROT_READ) if it helps since this is POSIX compliant.

Maybe pari_mainstack_malloc could take both size in arguments
and do both mmap at once.

Did you try madvise(, MADV_DONTNEED) ?

> But the trick is known and used
> in the wild, see for example the discussion
> 
> https://github.com/jemalloc/jemalloc/issues/255

which links to 
<https://github.com/jemalloc/jemalloc/issues/193>
which says:

"
  The overcommit heuristic is clearly not sensible when using jemalloc, so
  I think it would make sense to detect it and set MAP_NORESERVE on all of
  the mappings. Rather than catching obvious errors, it's resulting in an
  inability to use all of (well, more than half of) the system's
  resources. Alternatively, MAP_NORESERVE could just be set by default.
  It's a no-op for the other 2 overcommit states (it's not documented
  correctly in the man pages project).
"

But your patch remove MAP_NORESERVE. Why ?

Cheers,
Bill.