Re: How to handle TIF_MEMDIE stalls?

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Dave Chinner wrote:
> > Forever blocking kswapd0 somewhere inside filesystem shrinker functions is
> > equivalent with removing kswapd() function because it also prevents non
> > filesystem shrinker functions from being called by kswapd0, doesn't it?
> 
> Yes, but that's not intentional. Remember, we keep talking about the
> filesystem not being able to guarantee forwards progress if
> allocations block forever? Well...
> 
> > Then, the description will become "We won't have _some_ free memory available
> > if there is no other activity that frees anything up", won't it?
> 
> ... we've ended up blocking kswapd because it's waiting on a journal
> commit to complete, and that journal commit is blocked waiting for
> forwards progress in memory allocation...
> 
> Yes, it's another one of those nasty dependencies I keep pointing
> out that filesystems have, and that can only be solved by
> guaranteeing we can always make forwards allocation progress from
> transaction reserve to transaction commit.

If this is an unexpected deadlock, don't we want below change for
xfs_reclaim_inodes_ag() ?

-	if (skipped && (flags & SYNC_WAIT) && *nr_to_scan > 0) {
+	if (skipped && (flags & SYNC_WAIT) && *nr_to_scan > 0 && !current_is_kswapd()) {
 		trylock = 0;
 		goto restart;
 	}

> It's rare that kswapd actually gets stuck like this - I've only ever
> seen it once, and I've never had anyone running a production system
> report deadlocks like this...

I guess we will unlikely see this again, for so far this is observed with
only Linux 3.19 which lacks commit cc87317726f8 ("mm: page_alloc: revert
inadvertent !__GFP_FS retry behavior change").

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>