|
|
Log in / Subscribe / Register

Allowing small allocations to fail

Allowing small allocations to fail

Posted Mar 16, 2015 4:02 UTC (Mon) by ploxiln (subscriber, #58395)
In reply to: Allowing small allocations to fail by vbabka
Parent article: Allowing small allocations to fail

I've acutely experienced that problem, of extended struggling before invoking the OOM killer. I had swap completely disabled on my personal laptop for a few years in an attempt to avoid it, but it still eventually happened (virtual machines, browsers...). I use linux on both personal machines and popular-website-serving servers, and in both cases prefer "fail fast", instead of "go into uselessly slow mode".

I suppose someone will say to disable overcommit, but many runtimes, particularly nodejs, pretty much require it. Browsers of course require it. Lots of threads with large stacks they won't use, also use a lot of virt.


to post comments

Allowing small allocations to fail

Posted Mar 16, 2015 16:05 UTC (Mon) by vbabka (subscriber, #91706) [Link] (1 responses)

This is somewhat different problem. If OOM was not invoked, it means the reclaim still succeeded, so it wasn't a fail/nofail situation, however the system was already perceived as unusable. Reports such as yours appear from time to time, see e.g. https://lkml.org/lkml/2015/1/23/688 thread which even contains some candidate patch, but the reporter apparently didn't test it so far.

So if we call the OOM killer early, do we still get races?

Posted Mar 17, 2015 13:57 UTC (Tue) by gmatht (subscriber, #58961) [Link]

I think the point is that if the Kernel doesn't have 32KiB of clean pages left to dealloc, then from the point of an ordinary desktop, the system has already failed. It would already be unusable.

It is very hard to know *exactly* how much memory is needed to free a page. However, even on a low end 2GB netbook, and even if we reserve only 1% of ram for clean pages (and emergency allocations) that still allows a lot of "too small to fail" allocations. On most systems, reserving 10% would seem reasonable. On embedded systems without a disk it may not make much sense, but they may still have a use for Transcendent/ephemeral memory (and they probably aren't using XFS anyway).


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds