On Tue, Jan 26, 2016 at 10:50:23AM +0100, Michal Hocko wrote: > On Mon 25-01-16 13:45:59, Johannes Weiner wrote: > > Hi Michal, > > > > On Mon, Jan 25, 2016 at 02:33:57PM +0100, Michal Hocko wrote: > > > - GFP_NOFS is another one which would be good to discuss. Its primary > > > use is to prevent from reclaim recursion back into FS. This makes > > > such an allocation context weaker and historically we haven't > > > triggered OOM killer and rather hopelessly retry the request and > > > rely on somebody else to make a progress for us. There are two issues > > > here. > > > First we shouldn't retry endlessly and rather fail the allocation and > > > allow the FS to handle the error. As per my experiments most FS cope > > > with that quite reasonably. Btrfs unfortunately handles many of those > > > failures by BUG_ON which is really unfortunate. > > > > Are there any new datapoints on how to deal with failing allocations? > > IIRC the conclusion last time was that some filesystems simply can't > > support this without a reservation system - which I don't believe > > anybody is working on. Does it make sense to rehash this when nothing > > really changed since last time? > > There have been patches posted during the year to fortify those places > which cannot cope with allocation failures for ext[34] and testing > has shown that ext* resp. xfs are quite ready to see NOFS allocation > failures. The XFS situation is compeletely unchanged from last year, and the fact that you say it handles NOFS allocation failures just fine makes me seriously question your testing methodology. In XFS, *any* memory allocation failure during a transaction will either cause a panic through null point deference (because we don't check for allocation failure in most cases) or a filesystem shutdown (in the cases where we do check). If you haven't seen these behaviours, then you haven't been failing memory allocations during filesystem modifications. We need to fundamentally change error handling in transactions in XFS to allow arbitrary memory allocation to fail. That is, we need to implement a full transaction rollback capability so we can back out changes made during the transaction before the error occurred. That's a major amount of work, and I'm probably not going to do anything on this in the next year as it's low priority because what we have now works. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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>