From owner-freebsd-current@FreeBSD.ORG Mon Oct 22 21:08:56 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 D3C9516A417 for ; Mon, 22 Oct 2007 21:08:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 6056713C480 for ; Mon, 22 Oct 2007 21:08:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9ML8f61040515; Mon, 22 Oct 2007 15:08:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <471D1146.2050502@samsco.org> Date: Mon, 22 Oct 2007 15:08:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Julian Elischer References: <471BDA2E.9040801@elischer.org> In-Reply-To: <471BDA2E.9040801@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 22 Oct 2007 15:08:42 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org 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: Mon, 22 Oct 2007 21:08:56 -0000 Julian Elischer wrote: > Here is the link to the next patch. > > this introduces (back) the kthread_create (etc) calls but now they > make threads.. > It's still in the testing stage.. > I'd certainly appreciate feedback. > Especially as some of the locking and stuff has changed since I first > wrote this and tested it over 2 years ago. > > One possibility.. changing kthread_create() to kthread_new() > so that any people who are using the old kthread_create() don't get the new > one by mistake.... > > > after this is committed, I will start changing over some of the callers > of kproc_create, > one at a time.... > > > http://people.freebsd.org/~julian/kthread.diff > > > it may also be worth adding some help for people to make a new kproc, > and populate it with a number of kthreads. > > for instance it would be aesthetically pleasing to have a single idle > process, > and have all the idle threads be part of that single process. > > Similarly, might things like the syncer or other processes ever benefit > from having multiple threads? > Anyhow that's another discussion. Why is there a need for separate kprocs with their own private kthreads in the kernel? 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. 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? 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? Are there scheduling implications and benefits? 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? If I've missed the discussion on scheduling, I apologize. If not, have these questions been thought through yet? Scott