Re: How to handle TIF_MEMDIE stalls?

Linus Torvalds
2014-12-24T02:40:14Z

On Tue, Dec 23, 2014 at 5:06 PM, Dave Chinner <david@fromorbit.com> 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