[GHC] #14492: Tiered memory allocation restricts available memory
GHC
ghc-devs at haskell.org
Mon Nov 20 15:46:29 UTC 2017
#14492: Tiered memory allocation restricts available memory
-------------------------------------+-------------------------------------
Reporter: unode | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 8.0.2
Resolution: | Keywords: memory ulimit
Operating System: Linux | Architecture: x86_64
Type of failure: Poor/confusing | (amd64)
error message | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by unode):
Replying to [comment:1 bgamari]:
> I suppose we could set an upper bound on the reservation size. That is,
exponentially increase up to, e.g., 32GB and then from there allocate 32
GB at a time.
32GB might still be quite large of a slice. On a 64GB machine that would
be half of the total, making the software use at most ~32GB (since 64GB
wouldn't be reservable).
I don't know anything about GHC's internals so take this with a grain of
salt.
Would it make sense to instead half the previous reservation and keep
halfing if unsuccessful? Otherwise, on systems that rely on this `ulimit
-v` behavior, there will always be a gap between possible memory and what
the software is actually able to use.
My current understanding is that a process tries to reserve memory and
doesn't try to change this value during runtime. Is it correct to say that
any effort (or lack thereof) at start will constrain execution? If so
shouldn't a "reserve as much as the system allows" effort be the default?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14492#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list