On Wed, 16 Apr 2014 10:42:07 -0400 Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Wed, 16 Apr 2014 14:03:35 +1000
> NeilBrown <neilb@xxxxxxx> wrote:
>
> > Comments, criticisms, etc most welcome.
> >
> > Thanks,
> > NeilBrown
> >
>
> I've only given this a once-over, but the basic concept seems a bit
> flawed. IIUC, the basic idea is to disallow allocations done in knfsd
> threads context from doing fs-based reclaim.
>
> This seems very heavy-handed, and like it could cause problems on a
> busy NFS server. Those sorts of servers are likely to have a lot of
> data in pagecache and thus we generally want to allow them to do do
> writeback when memory is tight.
>
> It's generally acceptable for knfsd to recurse into local filesystem
> code for writeback. What you want to avoid in this situation is reclaim
> on NFS filesystems that happen to be from knfsd on the same box.
>
> If you really want to fix this, what may make more sense is trying to
> plumb that information down more granularly. Maybe GFP_NONETFS and/or
> PF_NETFSTRANS flags?
Hi Jeff,
a few clarifications first:
1/ These changes probably won't affect a "busy NFS server" at all. The
PF_FSTRANS flag only get set in nfsd when it sees a request from the local
host. Most busy NFS servers would never see that, and so would never set
PF_FSTRANS.
2/ Setting PF_FSTRANS does not affect where writeback is done. Direct
reclaim hasn't performed filesystem writeback since 3.2, it is all done
by kswapd (I think direct reclaim still writes to swap sometimes).
The main effects of setting PF_FSTRANS (as modified by this page set)
are:
- when reclaim calls ->releasepage __GFP_FS is not set in the gfp_t arg
- various caches like dcache, icache etc are not shrunk from
direct reclaim
There are other effects, but I'm less clear on exactly what they mean.
A flag specific to network filesystems might make sense, but I don't think it
would solve all the deadlocks.
A good example is the deadlock with the flush-* threads.
flush-* will lock a page, and then call ->writepage. If ->writepage
allocates memory it can enter reclaim, call ->releasepage on NFS, and block
waiting for a COMMIT to complete.
The COMMIT might already be running, performing fsync on that same file that
flush-* is flushing. It locks each page in turn. When it gets to the page
that flush-* has locked, it will deadlock.
xfs_vm_writepage does allocate memory with __GFP_FS set
xfs_vm_writepage -> xfs_setfilesize_trans_alloc -> xfs_trans_alloc ->
_xfs_trans_allo
and I have had this deadlock happen. To avoid this we need flush-* to ensure
that no memory allocation blocks on NFS. We could set a PF_NETFSTRANS there,
but as that code really has nothing to do with networks it would seem an odd
place to put a network-fs-specific flag.
In general, if nfsd is allowed to block on local filesystem, and local
filesystem is allowed to block on NFS, then a deadlock can happen.
We would need a clear hierarchy
__GFP_NETFS > __GFP_FS > __GFP_IO
for it to work. I'm not sure the extra level really helps a lot and it would
be a lot of churn.
Thanks,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
