On 2020-Jan-28, at 11:33, Cy Schubert <Cy.Schubert at cschubert.com> wrote: > On January 27, 2020 2:25:59 PM PST, Mark Millard <marklmi_at_yahoo.com> wrote: >> . . . >> >> It would be nice to find out what category of issue in the kernel >> is driving the OOM kills for your 5GB context with MAKE_JOBS_NUMBER=4. >> Too bad the first kill does not report a backtrace spanning the >> code choosing to do the kill (or otherwise report the type of issue >> leading the the kill). >> >> Your is consistent with the small arm board folks reporting that >> recently >> contexts that were doing buildworld and the like fine under somewhat >> older kernels have started getting OOM kills, despite the two settings. >> >> At the moment I'm not sure how to find the category(s) of issue(s) that >> is(are) driving these OOM kills. >> >> Thanks for reporting what settings you were using. >> >> . . . > > I've been able to reproduce the problem at $JOB in a Virtualbox VM with 1 vCPU, 1.5 GB vRAM, and 2 GB swap building graphics/graphviz: cc killed out of swap space. The killed cc had an address space of ~ 500 MB, using only 43 MB of the 2 GB swap. Free space is exhausted but swap used never exceeds tens of MB. Doubling the swap to 4 GB had no effect. The VM doesn't use ZFS. > > This appears recent. > head -r357026 turned some code that previously avoided vm_pageout_oom(VM_OOM_MEM_PF) into code that always does it for the conditions that should avoid the call. In part, this disabled what we were doing vm.pfault_oom_attempts="-1" for: that case now always kills. Head -r357025 is the last version to avoid the call (until this is fixed). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Tue Jan 28 2020 - 18:49:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC