On Thu 02-04-15 08:39:02, Dave Chinner wrote: > On Wed, Apr 01, 2015 at 05:19:20PM +0200, Michal Hocko wrote: > > On Mon 30-03-15 11:32:40, Dave Chinner wrote: > > > On Fri, Mar 27, 2015 at 11:05:09AM -0400, Johannes Weiner wrote: > > [...] > > > > GFP_NOFS sites are currently one of the sites that can deadlock inside > > > > the allocator, even though many of them seem to have fallback code. > > > > My reasoning here is that if you *have* an exit strategy for failing > > > > allocations that is smarter than hanging, we should probably use that. > > > > > > We already do that for allocations where we can handle failure in > > > GFP_NOFS conditions. It is, however, somewhat useless if we can't > > > tell the allocator to try really hard if we've already had a failure > > > and we are already in memory reclaim conditions (e.g. a shrinker > > > trying to clean dirty objects so they can be reclaimed). > > > > > > From that perspective, I think that this patch set aims force us > > > away from handling fallbacks ourselves because a) it makes GFP_NOFS > > > more likely to fail, and b) provides no mechanism to "try harder" > > > when we really need the allocation to succeed. > > > > You can ask for this "try harder" by __GFP_HIGH flag. Would that help > > in your fallback case? > > That dips into GFP_ATOMIC reserves, right? What is the impact on the > GFP_ATOMIC allocations that need it? Yes the memory reserve is shared but the flag would be used only after previous GFP_NOFS allocation has failed which means that that the system is close to the OOM and chances for GFP_ATOMIC allocations (which are GFP_NOWAIT and cannot perform any reclaim) success are quite low already. > We typically see network cards fail GFP_ATOMIC allocations before XFS > starts complaining about allocation failures, so i suspect that this > might just make things worse rather than better... My understanding is that GFP_ATOMIC allocation would fallback to GFP_WAIT type of allocation in the deferred context in the networking code. There would be some performance hit but again we are talking about close to OOM conditions here. -- Michal Hocko SUSE Labs -- 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>