kernel thread as real threads..
jhb at freebsd.org
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
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 FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current