From owner-svn-src-all@FreeBSD.ORG Thu Jan 3 20:50:13 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3728B2CA; Thu, 3 Jan 2013 20:50:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7547D2EE; Thu, 3 Jan 2013 20:50:12 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66CF4B9AD; Thu, 3 Jan 2013 15:50:09 -0500 (EST) From: John Baldwin To: Jim Harris Subject: Re: svn commit: r244549 - head/sys/dev/nvme Date: Thu, 3 Jan 2013 15:44:52 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212211913.qBLJDmpm019837@svn.freebsd.org> <201212211424.16934.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301031544.52750.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Jan 2013 15:50:11 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:50:13 -0000 On Friday, December 21, 2012 04:49:13 PM Jim Harris wrote: > On Fri, Dec 21, 2012 at 12:24 PM, John Baldwin wrote: > > On Friday, December 21, 2012 2:13:48 pm Jim Harris wrote: > > > Author: jimharris > > > Date: Fri Dec 21 19:13:48 2012 > > > New Revision: 244549 > > > URL: http://svnweb.freebsd.org/changeset/base/244549 > > > > > > Log: > > > Put kthreads under curproc so they are attached to nvmecontrol rather > > > than pid 0. > > > > > > Sponsored by: Intel > > > > Hmm, is this really wise? I'm not sure how well the kernel would handle > > a kthread belonging to a userland process. You could just have each > > test create a new kproc that holds the associated threads for that test > > instead perhaps? > > Just so I'm aware, what sorts of problems might you expect if a kthread > belongs to a userland process? I'm not opposed to changing this as you > suggest, but would like to know for my own understanding since I haven't > observed any problems with it on my system. I'm not sure what might break. :( I just know that I have always expected a kthread to belong to a kernel process, and it wouldn't surprise me if there wasn't some code somewhere that assumed TDP_KTHREAD implied that the associated process as a kernel process (P_SYSTEM). Perhaps it would work, but I don't think many folks have considered that edge case or coded for it. OTOH, it might be an interesting way to implement aio (though I think aio should be implemented directly in userland using user threads, though possibly not pthreads so a single-threaded application doesn't pay a penalty). -- John Baldwin