kernel thread as real threads..
julian at elischer.org
Mon Jan 23 14:45:47 PST 2006
John Baldwin wrote:
>On Monday 23 January 2006 17:22, Julian Elischer wrote:
>>John Baldwin wrote:
>>>On Thursday 19 January 2006 21:56, Julian Elischer wrote:
>>>>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.
the aim of ksegroups is simply as containers sothat you can group
threads from a scheduler perspective.
The kernel threads code I have in the patch automatically creates system
sscope threads by associating
them each with a separate kseg (ksegs are small) however it might by
fairer to group multiple
aio threads into a single ksegrp so that you don't flood the system if
you make a lot of them..
of course that brings up teh question as to whether a process doing AIO
would require just a single thread or
a bunch if them.. (do you want a separate thread per aio request or to
multiplexing them saves resources (and may be more extensible) but
having a single blocking thread per
request would be really simple and easy to debug.... I guess the
current multiplexeing code would work for
multiplexed threads. you could just drop the vm futzing code.
More information about the freebsd-current