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

From: Avi Kivity
Date: Thu Jul 29 2004 - 11:17:16 EST


Nick Piggin wrote:

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.

We attempted to use sync local mounts (not what you are suggesting: on the NFS client side, without the PF_MEMALLOC hack) and still got the same deadlock. I am unable to explain why.



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!

It was my pleasure.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-
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/