On Tue, Dec 23, 2014 at 5:06 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> Worse, it can be the task that is consuming all the memory, as canbe
> seen by this failure on xfs/084 on my single CPU. 1GB RAM VM. This
> test has been failing like this about 30% of the time since 3.18-rc1:
Quite frankly, uif you can realiably handle memory allocation failures
and they won't cause problems for other processes, you should use
GFP_USER, not GFP_KERNEL.
GFP_KERNEL does mean "try really hard". That has *always* been true.
We used to have a __GFP_HIGH set in GFP_KERNEL exactly for that
reason.
We seem lost that distinction between GFP_USER and GFP_KERNEL long
ago, and then re-grew it in a weaker form as GFP_HARDWALL. That may be
part of the problem: the kernel cannot easily distinguish between "we
should try really hard to satisfy this allocation" and "we can easily
fail it".
Maybe we could just use that GFP_HARDWALL bit for it. Possibly rename
it, but for *testing* it somebody could try this trivial/minimal
test-patch.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7633c503a116..7cacd45b47ce 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2307,6 +2307,10 @@ should_alloc_retry(gfp_t gfp_mask, unsigned
int order,
if (!did_some_progress && pm_suspended_storage())
return 0;
+ /* GFP_USER allocations don't re-try */
+ if (gfp_mask & __GFP_HIGHWALL)
+ return 0;
+
/*
* In this implementation, order <= PAGE_ALLOC_COSTLY_ORDER
* means __GFP_NOFAIL, but that may not be true in other
which is intentionally whitespace-damaged, because it really is meant
as a "this is a starting point for experimentation by VM people"
rather than as a "apply this patch and you're good to go" patch..
Hmm?
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>