Re: [PATCH] Deadlock during heavy write activity to userspace NFSserver on local NFS mount

[Nick Piggin]

Avi Kivity wrote:
> Nick Piggin wrote:
>
> > Avi Kivity wrote:
> >
> > > Nick Piggin wrote:
> >
> >
> >
> > > > > What's stopping the NFS server from ooming the machine then? Every 
> > > > > time some bit of memory becomes free, the server will consume it 
> > > > > instantly. Eventually ext3 will not be able to write anything out 
> > > > > because it is out of memory.
> > > > The NFS server should do the writeout a page at a time.
> > >
> > >
> > >
> > >
> > > The NFS server writes not only in response to page reclaim (as a 
> > > local NFS client), but also in response to pressure from non-local 
> > > clients. If both ext3 and NFS have the same allocation limits, NFS 
> > > may starve out ext3.
> >
> > What do you mean starve out ext3? ext3 gets written to *by the NFS 
> > server*
> > which is PF_MEMALLOC. 
>
>
> When the NFS server writes, it allocates pagecache and temporary 
> objects. When ext3 writes, it allocates temporary objects. If the NFS 
> server writes too much, ext3 can't allocate memory, and will never be 
> able to allocate memory.

That is because your NFS server shouldn't hog as much memory as
it likes when it is PF_MEMALLOC. The entire writeout path should
do a page at a time if it is PF_MEMALLOC. Ie, the server should
be doing write, fsync.

But now that I think about it, I guess you may not be able to
distinguish that from regular writeout, so doing a page at a time
would hurt performance too much.

Hmm so I guess the idea of a per task reserve limit may be the way
to do it, yes. Thanks for bearing with me!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/