Re: More OOM problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 18, 2016 at 2:00 PM, Vlastimil Babka <vbabka@xxxxxxx> wrote:
>
> Sounds like SLUB. SLAB would use order-0 as long as things fit. I would
> hope for SLUB to fallback to order-0 (or order-1 for 8kB) instead of
> OOM, though. Guess not...

SLUB it is - and I think that's pretty much all the world these days.
SLAB is largely deprecated.

We should probably start to remove SLAB entirely, and I definitely
hope that no oom people run with it. SLUB is marked default in our
config files, and I think most distros follow that (I know Fedora
does, didn't check others).

> Well, order-3 is actually PAGE_ALLOC_COSTLY_ORDER, and costly orders
> have to be strictly larger in all the tests. So order-3 is in fact still
> considered "small", and thus it actually results in OOM instead of
> allocation failure.

Yeah, but I do think that "oom when you have 156MB free and 7GB
reclaimable, and haven't even tried swapping" counts as obviously
wrong.

I'm not saying the code should fail and return NULL either, of course.

So  PAGE_ALLOC_COSTLY_ORDER should *not* mean "oom rather than return
NULL". It really has to mean "try a _lot_ harder".

                 Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]