> The NFS case poses one more problem. If the code to sleep for available
> resources is inside the filesystem code itself, an nfsd may
> sleep waiting for resources. This is fine for a normal process,
> but an nfsd could be doing other useful things., like serving
> requests for other filesystems. If you have something like VOP_THROTTLE,
> you can pass it a flag saying "don't sleep, just report EAGAIN", at
> which point you can requeue the request (making sure you don't
> get starvation of course), and serve some other requests.

I don't actually see a problem blocking the nfs process.  In some
sense you are blocking it before the call rather than during it
(which would be the more usual case).  In any case the system runs
multiple nfsd processes so that some can block.

(Is there another problem here with the fact that nfs requests aren't
supposed to be acked until the relevant data is on disk?)

Since (I presume) softdeps ends up doing fewer disk transfers, it will
run faster in the long term (even when limited by kmem space).  So the
delays seem will be less (on average) than without it.

I'd also guess that you only need block a process for a very short time.
Which probably won't be noticable...
> 
> Now, you could make all VOPs just return EAGAIN (or a similar error)
> in case of resource shortage. But then you have to teach all of
> the fs code to deal with that. That would be a big problem.

There is also to question of what the code does when it gets the EAGAIN
response.  Retrying immediately is fruitless.  Often the best bet is
a short delay (poll(0,0,1) from userspace) and retry...
> 
> > Yes - but something needs to tell the softdeps code that it better
> > release some of its resources (or is it always doing it as fast as
> > it can?).  The process it does the releasing doesn't have to be the
> > one that made the request - indeed, as you said, that isn't a good
> > place to try.
> 
> The problem is, even if you tell the syncer to get rid of dependencies
> as fast as it can, there is still no guarantee that there isn't a process
> that is adding requests more quickly than they can be pushed out
> to disk. This is the basic problem that I'm trying to address here.

Is there actually a deadlock if you sleep the process when it tries to
add a request?

    David