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 <mark...@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)
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
