Date: Mon, 23 Jan 2006 23:28:17 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: kernel thread as real threads.. Message-ID: <20060123232315.O48094@fledge.watson.org> In-Reply-To: <200601231739.02247.jhb@freebsd.org> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <200601231739.02247.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060123232315.O48094>