#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