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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>