Subject: Re: uvm deadlock against nfs w/ loopback-interface mounts?
To: Bill Studenmund <wrstuden@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 12/09/2002 13:41:50
In message <Pine.NEB.4.33.0212091312560.15911-100000@vespasia.home-net.internet
connect.net>Bill Studenmund writes:
>On Mon, 9 Dec 2002, Jonathan Stone wrote:

The "don't do this" doesnt really cut it for me.  You might as well
tell me to go use FreeBSD. Nothing personal, thats just how it is.

>This deadlock issue has been known about for a while (like longer than
>I've been a NetBSD developer), and there's no easy fix.

Ouch. Sorry, I must've forgotten somewhere along the thesis path.

>The problem isn't just for NFS. msdosfs can do it too (as Roland found out
>a few years ago). The problem is that to free pages, sometimes we need
>pages. NFS needs mbufs to send data to clean cache contents, msdosfs needs
>to read blocks to figure out where to write blocks, etc.
>
>While I'd love for us to fix it, I'm not 100% sure how to do it.

Perhaps create a special "reserve-tank" pool of pages, for term use by
kernel callers (filesystems; anything else?) who "promise" to (a) use
the page for short-term use only, and (b) to use the page to free more
pages than they obtained from this pool?

As I said; I can imagine kludging the uvm parameters to get the same
overal effect. I'm looking for ideas for a `proper' fix.

FWIW, I did try FreeBSD, and couldn't persuade it to fail under this
particular load scenario. Anyone know how they avoid it, and if the
technique is worth copying/emulating?


>Take care,

Likewise, and thanks for the reminder.