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_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. 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. yesReceived on Tue Oct 23 2007 - 16:00:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:20 UTC