From owner-freebsd-current@FreeBSD.ORG Tue Oct 23 18:00:19 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED1F216A41A for ; Tue, 23 Oct 2007 18:00:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id E7B7213C4A5 for ; Tue, 23 Oct 2007 18:00:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 23 Oct 2007 11:00:13 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1A4E11267C4; Tue, 23 Oct 2007 11:00:13 -0700 (PDT) Message-ID: <471E36C6.4000205@elischer.org> Date: Tue, 23 Oct 2007 11:00:38 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kostik Belousov References: <471BDA2E.9040801@elischer.org> <471D1146.2050502@samsco.org> <471D49D4.5010607@elischer.org> <20071023085755.GI2012@deviant.kiev.zoral.com.ua> In-Reply-To: <20071023085755.GI2012@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: kthreads->kproc and back to kthread.. next patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 18:00:20 -0000 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