xfs
[Top] [All Lists]

Re: How to handle TIF_MEMDIE stalls?

To: Michal Hocko <mhocko@xxxxxxx>
Subject: Re: How to handle TIF_MEMDIE stalls?
From: Stefan Ring <stefanrin@xxxxxxxxx>
Date: Fri, 20 Feb 2015 14:37:00 +0100
Cc: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>, dchinner@xxxxxxxxxx, oleg@xxxxxxxxxx, Linux fs XFS <xfs@xxxxxxxxxxx>, hannes@xxxxxxxxxxx, linux-mm@xxxxxxxxx, mgorman@xxxxxxx, rientjes@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, fernando_b1@xxxxxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g/0BBZiqiuKxWqQvX17aHAdNoQ273hfu7SHpQLWeRC8=; b=GtKf0p7GbZ04o/a9Esoe3gKkX39BxHLiHQ8fe9Ao/KgD5g/g3nUIJrX5IKvZK9tjJj jIjrHZyq8nEJN0uoKLCsAWRnxsF1c5mFKW6iXCdDUaO+DMZrywrdRXQ9+EHBEBTBWvIQ nYAylrv2L3oEq6bgykY3Wd0/DuxuKyV2BPqJ80VFyoLRF0m36hSSk4XC2DkI+99Z5514 YjdwjlvKp7sEA0/v3aPhjHCRSjNtwWBuV0Wr7b2YP9rPXHGXOwCBr7BORGtfgZvle6o9 YWbyJQX07JueDnEWMuAvvZoLUJHJnzGtV4mY7ZkT1waYbObBqWE0mqJn1lhhWrDRmYaR 3m8w==
In-reply-to: <20150220091326.GD21248@xxxxxxxxxxxxxx>
References: <20150218104859.GM12722@dastard> <20150218121602.GC4478@xxxxxxxxxxxxxx> <20150219110124.GC15569@xxxxxxxxxxxxxxxxxxxxxx> <20150219122914.GH28427@xxxxxxxxxxxxxx> <20150219125844.GI28427@xxxxxxxxxxxxxx> <201502200029.DEG78137.QFVLHFFOJMtOOS@xxxxxxxxxxxxxxxxxxx> <20150220091326.GD21248@xxxxxxxxxxxxxx>
>> We don't know how many callers will pass __GFP_NOFAIL. But if 1000
>> threads are doing the same operation which requires __GFP_NOFAIL
>> allocation with a lock held, wouldn't memory reserves deplete?
>
> We shouldn't have an unbounded number of GFP_NOFAIL allocations at the
> same time. This would be even more broken. If a load is known to use
> such allocations excessively then the administrator can enlarge the
> memory reserves.
>
>> This heuristic can't continue if memory reserves depleted or
>> continuous pages of requested order cannot be found.
>
> Once memory reserves are depleted we are screwed anyway and we might
> panic.

This discussion reminds me of a situation I've seen somewhat
regularly, which I have described here:
http://oss.sgi.com/pipermail/xfs/2014-April/035793.html

I've actually seen it more often on another box with OpenVZ and
VirtualBox installed, where it would almost always happen during
startup of a VirtualBox guest machine. This other machine is also
running XFS. I blamed it on OpenVZ or VirtualBox originally, but
having seen the same thing happen on the other machine with neither of
them, the next candidate for taking blame is XFS.

Is this behavior something that can be attributed to these memory
allocation retry loops?

<Prev in Thread] Current Thread [Next in Thread>