Re: kernel thread as real threads..

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