Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Oct 2007 11:00:38 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        current@freebsd.org
Subject:   Re: kthreads->kproc and back to kthread.. next patch
Message-ID:  <471E36C6.4000205@elischer.org>
In-Reply-To: <20071023085755.GI2012@deviant.kiev.zoral.com.ua>
References:  <471BDA2E.9040801@elischer.org> <471D1146.2050502@samsco.org> <471D49D4.5010607@elischer.org> <20071023085755.GI2012@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote:
> 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.
true, but there is more to a process than vmspace.
generally making things threads that don't need to be 
processes can remove quite a bit of cruft.

I'm still working on the replacement kthread_xxx code.
i have a working version but there are some aesthetic issues I'm looking at.

> 
> Some time ago I have reported to alc@ (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.

We're looking at it..

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

yes

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

yes




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?471E36C6.4000205>