From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 23:27:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D759D16A41F; Mon, 23 Jan 2006 23:27:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5760843D4C; Mon, 23 Jan 2006 23:27:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 350F746C2E; Mon, 23 Jan 2006 18:27:02 -0500 (EST) Date: Mon, 23 Jan 2006 23:28:17 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200601231739.02247.jhb@freebsd.org> Message-ID: <20060123232315.O48094@fledge.watson.org> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <200601231739.02247.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: kernel thread as real threads.. 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, 23 Jan 2006 23:27:09 -0000 On Mon, 23 Jan 2006, John Baldwin wrote: > That's probably a better model, yes. One thing I would prefer though is if > we could limit the knowledge of ksegroups to the scheduler as much as > possible and let the rest of the kernel just deal with threads and > processes. Ideally, we'd reach the point where you have an API to say > "create a thread for process p" and kthreads just use a kernel process for > 'p' and maybe the API takes a flag to say if a thread is separate or not. > Really, aio should probably just be separate system scope threads, and you > could almost do that in userland now. That was my hope also when we originally talked about KSE support -- really what you want the application to do is simply create kernel execution sessions, in effect kernel thread stacks, as required to avoid interrupting application execution. I identified three reasons why I ended up concluding it should stay in kernel (regardless of the kernel details -- kprocs, kthreads, etc): (1) I wasn't sure what the POSIX requirements for completing I/O after a process exits. Are we obligated to try and commit them asynchronously from process exit, stall process exit waiting on the I/O, or can we actually drop the I/O work? I'm pretty sure the last of these is undesirable, but we should find out. (2) Right now we can actually run aio code in kernel without dedicating a thread stack to it -- we have to use a full kernel thread stack for the duration of VFS operations, but for sockets we can perform queued I/O and use socket upcalls to pick up the competion event, avoiding committing a full aio daemon. This is sort of like Mach continuations, and should conserve kernel memory and other state (pid slots, etc) nicely. This cannot be replicated easily from user space using the normal I/O system calls, as those all commit kernel threads to the work, at least, if you do it the easy way. Even if you do it the complicated way, there's potentially a lot more transition in and out of user space. (3) When emulating systems that provide AIO via the kernel, we'll end up simply implemnting AIO all over again for those ABI layers, even if it's not used for FreeBSD. If we would like to change the threading model for aio, my leaning is to try to keep it all inside the kernel. Robert N M Watson