On Wed 25-11-15 02:59:19, David Rientjes wrote:
> On Wed, 25 Nov 2015, Michal Hocko wrote:
[...]
> > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> > if (zonelist_rescan)
> > goto zonelist_scan;
> >
> > + /* WARN only once unless min_free_kbytes is updated */
> > + if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> > + warn_alloc_no_wmarks = 0;
> > + WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> > + " You might consider increasing min_free_kbytes\n",
> > + order, gfp_mask);
> > + }
> > return NULL;
> > }
> >
>
> Doesn't this warn for high-order allocations prior to the first call to
> direct compaction whereas min_free_kbytes may be irrelevant?
Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
which happen prior to compaction, right? I am wondering whether there
are reasonable chances that a compaction would make a difference if we
are so depleted that there is no single page with >= order.
ALLOC_NO_WATERMARKS with high order allocations should be rare if
existing at all.
> Providing
> the order is good, but there's no indication when min_free_kbytes may be
> helpful from this warning.
I am not sure I understand what you mean here.
> WARN() isn't even going to show the state of memory.
I was considering to do that but it would make the code unnecessarily
more complex. If the allocation is allowed to fail it would dump the
allocation failure. The purpose of the message is to tell us that
reserves are not sufficient. I am not sure seeing the memory state dump
would help us much more.
--
Michal Hocko
SUSE Labs
--
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>