summaryrefslogtreecommitdiff
path: root/rts/posix/OSMem.c
Commit message (Collapse)AuthorAgeFilesLines
* Update error message to suggest the user consider OOM over RTS bug.Thomas M. DuBuisson2021-09-171-1/+3
| | | | Fix #17039
* Make `PosixSource.h` installed and under `rts/`John Ericson2021-08-091-1/+1
| | | | | | is used outside of the rts so we do this rather than just fish it out of the repo in ad-hoc way, in order to make packages in this repo more self-contained.
* Rename itimer to ticker in rts/posix for consistency.Andreas Klebinger2021-07-271-1/+1
|
* OSMem.c: Use proper type for mbinds mask argument.Andreas Klebinger2020-12-181-1/+1
| | | | | StgWord has different widths on 32/64bit. So use the proper type instead.
* Workaround for #18623: GHC crashes bc. under rlimit for vmem it will reserveBenjamin Maurer2020-09-291-5/+52
| | | | | | _all_ of it, leaving nothing for, e.g., thread stacks. Fix will only allocate 2/3rds and check whether remainder is at least large enough for minimum amount of thread stacks.
* Fix more typosBrian Wignall2019-12-021-1/+1
|
* Add +RTS --disable-delayed-os-memory-return. Fixes #17411.Niklas Hambüchen2019-11-011-13/+37
| | | | | | Sets `MiscFlags.disableDelayedOsMemoryReturn`. See the added `Note [MADV_FREE and MADV_DONTNEED]` for details.
* Expunge #ifdef and #ifndef from the codebaseJohn Ericson2019-07-141-3/+3
| | | | | | | | These are unexploded minds as far as the linter is concerned. I don't want to hit in my MRs by mistake! I did this with `sed`, and then rolled back some changes in the docs, config.guess, and the linter itself.
* RTS: Fix restrictive castAlec Theriault2019-05-221-2/+2
| | | | | | | | | | | | | Commit e75a9afd2989e0460f9b49fa07c1667299d93ee9 added an `unsigned` cast to account for OSes that have signed `rlim_t` signed. Unfortunately, the `unsigned` cast has the unintended effect of narrowing `rlim_t` to only 4 bytes. This leads to some spurious out of memory crashes (in particular: Haddock crashes with OOM whenn building docs of `ghc`-the-library). In this case, `W_` is a better type to cast to: we know it will be unsigned too and it has the same type as `*len` (so we don't suffer from accidental narrowing).
* osReserveHeapMemory: handle signed rlim_tFraser Tweedale2019-04-231-2/+4
| | | | | | rlim_t is a signed type on FreeBSD, and the build fails with a sign-compare error. Add explicit (unsigned) cast to handle this case.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-1/+1
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* rts: Fix unused functionBen Gamari2018-08-011-1/+2
|
* Enable two-step allocator on FreeBSDBen Gamari2018-07-311-53/+88
| | | | | | Simplify #ifdef nesting and use MAP_GUARD on FreeBSD and similar systems. This allows the two-step allocator to be used on FreeBSD, fixing #15348.
* fix osReserveHeapMemory block alignmentSergei Trofimovich2018-07-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the change osReserveHeapMemory() attempted to allocate chunks of memory via osTryReserveHeapMemory() not multiple of MBLOCK_SIZE in the following fallback code: ``` if (at == NULL) { *len -= *len / 8; ``` and caused assertion failure: ``` $ make fulltest TEST=T11607 WAY=threaded1 T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457 (GHC version 8.7.20180716 for riscv64_unknown_linux) ``` The change applies alignment mask before each MBLOCK allocation attempt and fixes WAY=threaded1 test failures on qemu-riscv64. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: run 'make fulltest WAY=threaded1' Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4982
* Revert "rts: Enable two-step allocator on FreeBSD"Ben Gamari2018-07-061-8/+3
| | | | | | This reverts commit 8736715857d08cc1f88d766c257b39c05df20639. I hadn't intended on merging this.
* rts: Enable two-step allocator on FreeBSDBen Gamari2018-07-061-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we would prevent any operating system not providing the MEM_NORESERVE flag from using the two-step allocator. Afterall, Linux will reserve swap-space for a mapping unless this flag is given, which is most certainly not what we want. However, it seems that FreeBSD provides the reservation-only mapping behavior that we expect despite not providing the MEM_NORESERVE macro. In fact, it provided the macro until 2014, when it was removed on account of not being implemented in the kernel. However, empirical evidence suggests that just plain mmap does what we want. Reviewers: erikd, simonmar Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #15348 Differential Revision: https://phabricator.haskell.org/D4939
* rts: Ignore RLIMIT_AS if it is zeroBen Gamari2018-06-141-1/+3
| | | | | | | | | | | | Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4811
* rts: Query system rlimit for maximum address-space sizeBen Gamari2018-06-021-0/+11
| | | | | | | | | | | | | | | | | When we attempt to reserve the heap, we query the system's rlimit to establish the starting point for our search over sizes. Test Plan: Validate Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4754
* rts/posix: Use less aggressive backoff schedule for heap reservation sizingBen Gamari2018-05-301-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we allocate the heap on POSIX platforms we generally just ask for a 1TB chunk of address space and call it a day. However, if the user has set a ulimit then this request will fail. In this case we would previously try successively smaller allocation requests, reducing the request size by a factor of two each time. However, this means that GHC will significantly allocate a significantly smaller heap than the available physical memory size in some circumstances. Imagine, for instance, a machine with 512 GB of physical memory but a ulimit of 511 GB: we would be limited to a 256 GB heap. We now use a less aggressive back-off policy, reducing by one-eighth the last allocation size each try. Thanks to luispedro for the suggested approach. Test Plan: Validate Reviewers: simonmar, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4215
* rts: Don't madvise if mmap failedBen Gamari2018-05-301-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit Linux `outofmem` did not fail with the expected out-of-memory error message, instead failing with, outofmem: internal error: getMBlock: mmap: Invalid argument This happened because, `my_mmap` would attempt to `madvise` even if the `mmap` call failed. So while `mmap` returns `ENOMEM` we nevertheless try to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL` error. Consequently we don't detect this to be an out-of-memory error. This should fix #15060. Test Plan: `make test TEST=outofmem` on i386 Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15060 Differential Revision: https://phabricator.haskell.org/D4704
* rts: Throw better error if --numa is used without libnuma supportBen Gamari2018-05-031-0/+9
| | | | | | | | | | | | | Test Plan: Validate, run program with `+RTS --numa` without libnuma support compiled in Reviewers: erikd, simonmar Subscribers: thomie, carter GHC Trac Issues: #14956 Differential Revision: https://phabricator.haskell.org/D4556
* rts: fix some barf format specifiers.Douglas Wilson2018-02-061-1/+1
| | | | | | | | | | Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4390
* rts: Fix format of failed memory commit messageBen Gamari2018-02-061-1/+1
| | | | | | | | | | | | Test Plan: Validate Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4373
* rts/posix: Ensure that memory commit succeedsBen Gamari2017-10-161-1/+4
| | | | | | | | | | | | | | | | | Previously we wouldn't check that mmap would succeed. I suspect this may have been the cause of #14329. Test Plan: Validate under low-memory condition Reviewers: simonmar, austin, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14329 Differential Revision: https://phabricator.haskell.org/D4075
* rts: Inform kernel that we won't need reserved address spaceBen Gamari2017-09-261-0/+13
| | | | | | | | | | | | | | | | | | | | | Trac #14192 points out that currently GHC's two-step allocator results in extremely large coredumps. It seems like WebKit may have encountered similar issues and their apparent solution uses madvise(MADV_DONTNEED) while reserving address space to inform the kernel that the address space we just requested needs no backing. Perhaps this is used by the core dump logic to trim out uncommitted pages. Test Plan: Validate, try core-dumping a compiled executable Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14192, #14193 Differential Revision: https://phabricator.haskell.org/D3929
* fix a memory leak in osNumaMaskKubo Kovac2017-05-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537
* Prefer #if defined to #ifdefBen Gamari2017-04-281-13/+13
| | | | Our new CPP linter enforces this.
* Enable new warning for fragile/incorrect CPP #if usageErik de Castro Lopo2017-04-281-4/+4
| | | | | | | | | | | | | | | | The C code in the RTS now gets built with `-Wundef` and the Haskell code (stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever `#if` is used on undefined identifiers. Test Plan: Validate on Linux and Windows Reviewers: austin, angerman, simonmar, bgamari, Phyx Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3278
* Revert "Enable new warning for fragile/incorrect CPP #if usage"Ben Gamari2017-04-051-4/+4
| | | | | | | | This is causing too much platform dependent breakage at the moment. We will need a more rigorous testing strategy before this can be merged again. This reverts commit 7e340c2bbf4a56959bd1e95cdd1cfdb2b7e537c2.
* Enable new warning for fragile/incorrect CPP #if usageErik de Castro Lopo2017-04-051-4/+4
| | | | | | | | | | | | | | | | The C code in the RTS now gets built with `-Wundef` and the Haskell code (stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever `#if` is used on undefined identifiers. Test Plan: Validate on Linux and Windows Reviewers: austin, angerman, simonmar, bgamari, Phyx Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3278
* Fix x86 Windows build and testsuiteTamar Christina2016-12-061-1/+1
| | | | | | | | | | | | | | | | Summary: Fix issues preventing x86 GHC to build on Windows and fix segfault in the testsuite. Test Plan: ./validate Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D2789
* rts: Ensure we always give MADV_DONTNEED a chance in osDecommitMemoryBen Gamari2016-12-011-3/+16
| | | | | | | | | | | | | | | | | | | | | As described in #12865, newer Linux kernels support both MADV_FREE and MADV_DONTNEED. Previously a runtime would fail to try MADV_DONTNEED if MADV_FREE failed (e.g. since the kernel which the image is running on doesn't support the latter). Now we try MADV_DONTNEED if MADV_FREE failed to ensure that binaries compiled on a kernel supporting MADV_FREE don't fail on decommit. Test Plan: Validate Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2780 GHC Trac Issues: #12865
* Use C99's boolBen Gamari2016-11-291-6/+6
| | | | | | | | | | | | Test Plan: Validate on lots of platforms Reviewers: erikd, simonmar, austin Reviewed By: erikd, simonmar Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2699
* Fix numa001 failure with "too many NUMA nodes"Simon Marlow2016-11-141-2/+2
| | | | | | | It seems that recent versions of the Linux kernel are using larger NUMA bitmasks; I see 1024 on my laptop running a 4.6.5 kernel. This causes the NUMA tests to fail. I'm fixing it to only fail if we have that many actual *nodes*, rather than failing if the size of the mask is too big.
* Make start address of `osReserveHeapMemory` tunable via command line -xbFrancesco Mazzoli2016-09-091-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We stumbled upon a case where an external library (OpenCL) does not work if a specific address (0x200000000) is taken. It so happens that `osReserveHeapMemory` starts trying to mmap at 0x200000000: ``` void *hint = (void*)((W_)8 * (1 << 30) + attempt * BLOCK_SIZE); at = osTryReserveHeapMemory(*len, hint); ``` This makes it impossible to use Haskell programs compiled with GHC 8 with C functions that use OpenCL. See this example ​https://github.com/chpatrick/oclwtf for a repro. This patch allows the user to work around this kind of behavior outside our control by letting the user override the starting address through an RTS command line flag. Reviewers: bgamari, Phyx, simonmar, erikd, austin Reviewed By: Phyx, simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2513
* rts: Fix NUMA when cross compilingErik de Castro Lopo2016-06-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | The NUMA code was enabled whenever numa.h and numaif.h are detected. Unfortunately, the hosts' header files were being detected even then cross compiling in the absence of a target libnuma. Fix that by relying on the the presence of libnuma instead of the presence of the header files. The test for libnuma does `AC_TRY_LINK` which will fail if the test program (compiled for the target) can't be linked against libnuma. Test Plan: Build on x86_64/linux and make sure NUMA works and cross compile to armhf/linux. Reviewers: austin, bgamari, hvr, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2329
* rts: Fix build when USE_LARGE_ADDRESS_SPACE is undefinedErik de Castro Lopo2016-06-121-2/+2
| | | | | | | | | | | | | | | | The recently added NUMA related functions were mistakenly defined within a `#ifdef USE_LARGE_ADDRESS_SPACE` ... `#endif` block. Moving them outside this block fixes the build on PowerPC and Arm Linux. Test Plan: Build on PowerPC or Arm Linux Reviewers: hvr, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2326
* NUMA supportSimon Marlow2016-06-101-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The aim here is to reduce the number of remote memory accesses on systems with a NUMA memory architecture, typically multi-socket servers. Linux provides a NUMA API for doing two things: * Allocating memory local to a particular node * Binding a thread to a particular node When given the +RTS --numa flag, the runtime will * Determine the number of NUMA nodes (N) by querying the OS * Assign capabilities to nodes, so cap C is on node C%N * Bind worker threads on a capability to the correct node * Keep a separate free lists in the block layer for each node * Allocate the nursery for a capability from node-local memory * Allocate blocks in the GC from node-local memory For example, using nofib/parallel/queens on a 24-core 2-socket machine: ``` $ ./Main 15 +RTS -N24 -s -A64m Total time 173.960s ( 7.467s elapsed) $ ./Main 15 +RTS -N24 -s -A64m --numa Total time 150.836s ( 6.423s elapsed) ``` The biggest win here is expected to be allocating from node-local memory, so that means programs using a large -A value (as here). According to perf, on this program the number of remote memory accesses were reduced by more than 50% by using `--numa`. Test Plan: * validate * There's a new flag --debug-numa=<n> that pretends to do NUMA without actually making the OS calls, which is useful for testing the code on non-NUMA systems. * TODO: I need to add some unit tests Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2199
* Runtime linker: Break m32 allocator out into its own fileErik de Castro Lopo2016-05-251-6/+6
| | | | | | | | | | | | | | | | | | | | This makes the code a little more modular and allows the removal of some CPP hackery. By providing dummy implementations of of the `m32_*` functions (which simply call `errorBelch`) it means that the call sites for these functions are syntax checked even when `RTS_LINKER_USE_MMAP` is `0`. Also changes some size parameter types from `unsigned int` to `size_t`. Test Plan: Validate on Linux, OS X and Windows Reviewers: Phyx, hsyl20, bgamari, simonmar, austin Reviewed By: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2237
* Get types in osFreeMBlocks in sync with osGetMBlocksTomas Carnecky2016-05-191-1/+1
| | | | | | | | | | | | | The first argument of 'osFreeMBlocks' ought to have the same type as the return value from 'osGetMBlocks'. Make it so. Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: erikd, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2235
* Remove use of caddr_tTomas Carnecky2016-05-191-4/+4
| | | | | | | | | | | | | | | | | > caddr_t is a legacy BSD type associated with some low level calls like > mmap, and it should never be used in modern code. It was rejected by > the POSIX standard. The standardized mmap uses void *. (http://stackoverflow.com/questions/6381526/what-is-the-significance-of- caddr-t-and-when-is-it-used) Reviewers: austin, simonmar, rwbarton, bgamari, erikd Reviewed By: rwbarton, bgamari, erikd Subscribers: erikd, thomie Differential Revision: https://phabricator.haskell.org/D2234
* rts: Replace `nat` with `uint32_t`Erik de Castro Lopo2016-05-051-2/+2
| | | | | | | | | | | | The `nat` type was an alias for `unsigned int` with a comment saying it was at least 32 bits. We keep the typedef in case client code is using it but mark it as deprecated. Test Plan: Validated on Linux, OS X and Windows Reviewers: simonmar, austin, thomie, hvr, bgamari, hsyl20 Differential Revision: https://phabricator.haskell.org/D2166
* Scrap IRIX supportHerbert Valerio Riedel2016-03-281-14/+1
| | | | | | | | | | | | | | | | Long time ago, IRIX was way ahead of its time in the last century with its SMP capabilities of scaling up to 1024 processors and other features such as XFS or OpenGL that originated in IRIX and live on to this day in other operating systems. However, IRIX's last software update was in 2006 and support ended around 2013 according to [1], so it's considered an extinct platform by now. So this commit message is effectively an obituary for GHC's IRIX support. R.I.P. IRIX [1]: https://en.wikipedia.org/wiki/IRIX
* rts/posix: Fail with HEAPOVERFLOW when out of memory during mmapBen Gamari2016-01-171-1/+1
| | | | | | | | | | | | Test Plan: Validate Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1787 GHC Trac Issues: #11300
* Allow to compile OSMem.c when MEM_NORESERVE is not availableHerbert Valerio Riedel2015-12-051-0/+7
| | | | | | | | | | | | On some OSes such as AIX `MEM_NORESERVE` is not available. Since this feature is only needed when the new two-step allocator (see #9706) is enabled we can simply turn this into a runtime error to avoid a larger refactoring of this already quite platform-sensitive code. Reviewed By: bgamari, ezyang Differential Revision: https://phabricator.haskell.org/D1568
* rts/posix: Reduce heap allocation amount on mmap failureBen Gamari2015-11-011-8/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since the two-step allocator the RTS asks the kernel for a large upfront mmap'd region of memory (on the order of terabytes). While we have no expectation that this entire region will be backed by physical memory, this scheme nevertheless fails on some systems with resource limits. Here we use a back-off scheme to reduce our allocation request until we find a size agreeable to the kernel. Fixes #10877. This also fixes a latent bug wherein the heap reservation retry logic would fail to free the previously reserved address space, which would likely result in a heap allocation failure. Test Plan: set address space limit with `ulimit -v 67108864` and try running a compiled program Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: thomie, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1405 GHC Trac Issues: #10877
* rts: Make MBLOCK_SPACE_SIZE dynamicBen Gamari2015-10-301-9/+10
| | | | | | | | | | | | | | | | | | | | | | | Previously this was introduced in D524 as a compile-time constant. Sadly, this isn't flexible enough to allow for environments where ulimits restrict the maximum address space size (see, for instance, Consequently, we are forced to make this dynamic. In principle this shouldn't be so terrible as we can place both the beginning and end addresses within the same cache line, likely incurring only one or so additional instruction in HEAP_ALLOCED. Test Plan: validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1353 GHC Trac Issues: #10877
* fix 64bit two-stage allocator on Solaris/AMD64 platform (#10790)Karel Gardas2015-08-251-1/+1
| | | | | | | | | | Test Plan: tested on Solaris 11/AMD64 when previous build failed Reviewers: bgamari, austin, simonmar, gcampax, ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1169
* Rejigger OSMem.my_mmap to allow building on MacRichard Eisenberg2015-08-061-28/+31
| | | | | | | | Previously, the prot and flags variables were set but never used on Mac (darwin). This caused a warning, and the build setup stopped compilation. This commit is intended simply to omit these variables when building with darwin_HOST_OS set. No change in behavior on any platform is intended.
* Two step allocator for 64-bit systemsGiovanni Campagna2015-07-221-24/+176
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current OS memory allocator conflates the concepts of allocating address space and allocating memory, which makes the HEAP_ALLOCED() implementation excessively complicated (as the only thing it cares about is address space layout) and slow. Instead, what we want is to allocate a single insanely large contiguous block of address space (to make HEAP_ALLOCED() checks fast), and then commit subportions of that in 1MB blocks as we did before. This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for certain OSes. Test Plan: validate Reviewers: simonmar, ezyang, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D524 GHC Trac Issues: #9706
View Lorry Controller Status