Re: How to handle an kmalloc failure in evict_inode()?

[Theodore Ts'o <tytso@mit.edu>]

On Sat, Aug 09, 2014 at 07:48:26PM +0900, Tetsuo Handa wrote:
> It seems to me that you are talking about only cases where memory allocation
> functions return NULL instead of waiting forever. But that is an optimistic
> assumption. What I'm observing under extreme memory pressure with XFS
> ( https://lkml.org/lkml/2014/7/2/249 ) is that memory allocation functions spin
> forever while keeping some of kernel threads locked. Do you have ideas for
> solving (or at least detecting) this behavior?

This is an mm problem.  I don't doubt that there are probably some
things that the mm can do a better job, but under a malicious /
abusive enough workload, the only solution is to OOM kill one or more
offending processes.

The mm layer can try to be more efficient at packing a certain amount
of sh*t into a bag, but ultimately, if you have 10 pounds of sh*t, and
a 5 pound bag, the bag is going to burst.  The only question is how
the bag is going to burst, and does so via just killing processes, or
whether you get some file system corruption in addition, as a bonus.

This is why I suspect the right answer is for the file system to use
GFP_NOFAIL instead of doing the retry loop inside the file system.
That gives the mm layer an easier way of getting a signal that things
are going bad, since the looping is done inside the slab allocator,
and so the mm can use this signal to decide if the time is right to
kick up the aggressiveness of the OOM killer.

     	    		      	      - Ted