Re: A peek at the future of storage

[J. Bruce Fields]

On Wed, Dec 12, 2007 at 07:39:25PM +0100, Bernd Petrovitsch wrote:
> On Mit, 2007-12-12 at 10:02 -0800, Daniel Phillips wrote:
> > On Wednesday 12 December 2007 09:46, J. Bruce Fields wrote:
> [...]
> > > People have proposed writing a daemon that just reads
> > > /proc/net/rpc/nfsd periodically and uses that to adjust the number of
> > > threads from userspace, probably subject to some limits in a config
> > > file someplace. (Think that could do the job, or is there some reason
> [...]
> > So how would a userspace daemon know that kernel is blocking and new 
> > threads are needed?

The last number on the "th" line in /proc/net/rpc/nfsd should tell you
how many seconds all threads have been busy (and previous lines tell you
how much time they've been 90% busy, etc).  That seems like sufficient
information at least for a rough guess.  It wouldn't allow as fast a
response time, but perhaps that doesn't matter.

> > In kernel this is pretty easy: when a new request 
> > arrives, look on the thread list and if none are available, generate a 
> > new one.  Something special needs to be done to handle the case where 
> > there are no threads available because they are all piled up on a 
> > semaphore due to, for example, somebody unplugging the network cable 
> > for a remote disk.

Ideally you'd like to limit the number of threads that that can happen
to, so that we still have a few threads free to handle rpc requests that
don't depend on some borked disk.  I don't know how to do that, though.

> > We have to avoid generating infinite threads in 
> > that case.  Ideas?
> 
> Add a sysctl configurable maximum number of NFS threads and default it
> to 8 (or whatever now the default value is).
> And one wants probably some logic to kill them again if they are not
> used long enough. And then you need/want another variable for the
> minimum number of NFS threads around.

If that's enough configuration for everyone, then fine.  If we suspect
people might need to do something more complicated, that might be an
argument for trying to do the tuning in userspace until we figure out
exactly what knobs are needed.

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