kernel thread as real threads..

John Baldwin jhb at
Mon Jan 23 14:57:23 PST 2006

On Monday 23 January 2006 17:22, Julian Elischer wrote:
> John Baldwin wrote:
> >On Thursday 19 January 2006 21:56, Julian Elischer wrote:
> >>some progrsss..
> >>as the first few lines show, it's not quite perfect yet but it's most of
> >>the way there..
> >>(Like proc 1 isn't init)
> >
> >One other note, watch out for the AIO daemons.  They have to be kernel
> > procs and not kthreads because they borrow the vmspace of the user
> > process when performing AIO on another process' behalf.
> yeah I found that and the patches account for that.
> However I would like to suggest that we change the way that aio works..
> My suggestion is that when a process does AIO, that we "fork a ksegroup"
> and attach it to the
> process, and assign it a (or some) worker thread to do the aio work.
> The userland process would
> be oblivious of the extra (kernel) threads in that kseg and they would
> be independently schedulable.
> They would however automatically have full access to the correct address
> space.

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.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-current mailing list