lkml.org 
[lkml]   [1996]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: nfsiod issues?
Date
From

In article <Pine.LNX.3.91.960417013234.239D-100000@gytha.demon.co.uk> you wrote:
: Hmm, shouldent the nfs module have no kernel threads running when it's
: not in use (compiled in/insmoded, but no mounts (yet/anymore) ).

The difficulty with kernel threads is that they are created by using
sys_clone(), which means that they inherit everything from the process
creating them, including its VM. This memory will not be released until
both the kernel thread and the process on behalf of which it was created
exit. This is the reason why nfsiod processes show up as insmod in the
ps listing. The bad thing about spawning nfsiod's when needed is that
if your first application happening to access a file on your NFS partition
happens to be emacs, you will be left with 18 MB of swap space occupied
for nothing.

I may change NFS to spawn and kill nfsiods when mounting/unmounting
volumes, but that fixes only the symptoms module users are seeing.
From the ps point of view you're merely exchanging insmod for mount.
Maybe a mechanism doing something like `init, please fork this kernel
thread for me' is needed. Maybe there's also a simple way a kernel
thread can release its associated VM, but I'm not aware of that.

: You (we) could have one nfsiod per imported tree, instead of 4 all at once

With the current rpcsock implementation, one nfsiod can serve only one
readahead request. Being able to serve 4 readahead requests in parallel
is optimal for most uses. As I said, I'm currently rewriting rpcsock.c
to use just one daemon.

Olaf
--
Olaf Kirch | this is not a cipher file -- PGP
okir@monad.swb.de | this is not a love song -- PiL


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.071 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site