Re: kthreads->kproc and back to kthread.. next patch

On Mon, Oct 22, 2007 at 06:09:40PM -0700, Julian Elischer wrote:
> >The kernel is a single unified address space; I thought
> >that the only real benefit to "true" kthreads was just elimination of
> >duplication of vmspaces for all off the kthreads that are currently
> >running around. 
> 
> yes, and the overhead that goes with it. i.e. double the number of 
> processes on an average system -> extra contention on process related locks 
> etc.

kproc_create() specifies RFMEM for the fork1() call, thus vmspace is
actually already shared.

Some time ago I have reported to alc_at_ (and I suspect this is what might
catalyzed the efforts) is that, for instance, nfs client creating kproc
for nfsiod while holding vnode locks easily leads to deadlock.

In the dump supplied by Peter Holm, nfs client trying to do
kproc_create() attempted to hold allproc_lock inside fork1() and held
some vnode lock. Other process in the page fault handler held vm map
lock and tried to acquire the vnode lock. To finish the lock loop,
sysctl handler vmtotal() aquired allproc lock and waited for lock of
the vm map.

Using kthread instead of kproc would eliminate allproc and related
locking.