Re: OOM detection regressions since 4.7

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, Aug 23, 2016 at 3:33 AM, Michal Hocko <mhocko@kernel.org> wrote:
>
> I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high
> order workloads that calling any change in that behavior a regression
> is little bit exaggerated.

Well, the thread info allocations certainly haven't been big problems
before. So regressing those would seem to be a real regression.

What happened? We've done the order-2 allocation for the stack since
May 2014, so that isn't new. Did we cut off retries for low orders?

So I would not say that it's an exaggeration to say that order-2
allocations failing is a regression.

Yes, yes, for 4.9 we may well end up using vmalloc for the kernel
stack, but there are certainly other things that want low-order
(non-hugepage) allocations. Like kmalloc(), which often ends up using
small orders just to pack data more efficiently (allocating a single
page can be hugely wasteful even if the individual allocations are
smaller than that - so allocating a few pages and packing more
allocations into it helps fight internal fragmentation)

So this definitely needs to be fixed for 4.7 (and apparently there's a
few patches still pending even for 4.8)

                 Linus

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