[Top] [All Lists]

Re: How to handle TIF_MEMDIE stalls?

To: Johannes Weiner <hannes@xxxxxxxxxxx>
Subject: Re: How to handle TIF_MEMDIE stalls?
From: Theodore Ts'o <tytso@xxxxxxx>
Date: Wed, 4 Mar 2015 12:38:41 -0500
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>, mhocko@xxxxxxx, dchinner@xxxxxxxxxx, linux-mm@xxxxxxxxx, rientjes@xxxxxxxxxx, oleg@xxxxxxxxxx, mgorman@xxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Hxo6moN5c06KDtbdNW2Kr9UXbMObTQEYaA/SR6FZ2vE=; b=uX1kba1UL3j+ymA619+9K2Oecxmth6krSoANNnwd3ayPRmR0kF9+NTFEEL6/WvqJyDlCHfHWdGcU2bCyAyM5MmlLoRTpso3/3jg+mhOeqEdgSppPetrez7f4WKP3cU9ghEWrNcVnjgNXrmcL+y2IIOkF+sBNH3GR2g0+1TSEJWw=;
In-reply-to: <20150304150436.GA16442@xxxxxxxxxxxxxxxxxxxxxx>
References: <20150219225217.GY12722@dastard> <20150221235227.GA25079@xxxxxxxxxxxxxxxxxxxxxx> <20150223004521.GK12722@dastard> <20150222172930.6586516d.akpm@xxxxxxxxxxxxxxxxxxxx> <20150223073235.GT4251@dastard> <20150302202228.GA15089@xxxxxxxxxxxxxxxxxxxxxx> <20150302231206.GK18360@dastard> <20150303025023.GA22453@xxxxxxxxxxxxxxxxxxxxxx> <20150304065242.GR18360@dastard> <20150304150436.GA16442@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
On Wed, Mar 04, 2015 at 10:04:36AM -0500, Johannes Weiner wrote:
> Yes, we can make this work if you can tell us which allocations have
> limited/controllable lifetime.

It may be helpful to be a bit precise about definitions here.  There
are a number of different object lifetimes:

a) will be released before the kernel thread returns control to

b) will be released once the current I/O operation finishes.  (In the
case of nbd where the remote server has unexpectedy gone away might be
quite a while, but I'm not sure how much we care about that scenario)

c) can be trivially released if the mm subsystem asks via calling a

d) can be released only after doing some amount of bounded work (i.e.,
cleaning a dirty page)

e) impossible to predict when it can be released (e.g., dcache, inodes
attached to an open file descriptors, buffer heads that won't be freed
until the file system is umounted, etc.)

I'm guessing that what you mean is (b), but what about cases such as

Would the mm subsystem find it helpful if it had more information
about object lifetime?  For example, the CMA folks seem to really care
about know whether memory allocations falls in category (e) or not.

                                                - Ted

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