From owner-freebsd-current@FreeBSD.ORG Tue Oct 23 01:09:33 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 E487F16A41B for ; Tue, 23 Oct 2007 01:09:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id B71B913C4A8 for ; Tue, 23 Oct 2007 01:09:28 +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; Mon, 22 Oct 2007 18:09:17 -0700 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 D398D126792; Mon, 22 Oct 2007 18:09:16 -0700 (PDT) Message-ID: <471D49D4.5010607@elischer.org> Date: Mon, 22 Oct 2007 18:09:40 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Scott Long References: <471BDA2E.9040801@elischer.org> <471D1146.2050502@samsco.org> In-Reply-To: <471D1146.2050502@samsco.org> 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 01:09:34 -0000 Scott Long wrote: a lot of questions: I'll separate them. > > Why is there a need for separate kprocs with their own private kthreads > in the kernel? Generally there is not. Hence this change. > 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. > Do I gain some sort of security or management benefit > from having my own private kproc for my kthreads, or am I really just > burning another vmspace object and nothing more? Except for the case of AIO, you are currently burning an extra proc structure for no reason. That's why I'm switching.. Realize that up until now all kernel threads have been full processes. What I'm doing is: 1/ changing the name of the exisitng function that makes processes to a name that actually says that. 2/ introducing a new function that makes an actual kernel THREAD. 3/ switching as many possible of the users to use the THREAD version. > What about the > existing fast context switching between kthreads (i.e. not flushing CR3 > on the switch), will that remain, or does it now get more complicated? It stays the same > Are there scheduling implications and benefits not really > > In fact for that > matter, how is scheduling going to be done for this? Is it all going to > be 1:1 style scheduling, or will there be a multi-tier scheduler for > kprocs and kthreads and associated niceness/fairness? What about high > priority kthreads like ithreads, taskqueues, and SWI's? no change. All threads are individually scheduled as they are now. > > If I've missed the discussion on scheduling, I apologize. If not, have > these questions been thought through yet? yes > > Scott