kernel thread as real threads..
David Xu
davidxu at freebsd.org
Mon Jan 23 18:24:46 PST 2006
Julian Elischer wrote:
>
>>> 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.
>>>
>> These threads should be invisible to userland debugger, and other code
>> current unknown, for example, signal code ? The idea seems simply but we
>> may in fact encounter problem, because you inject unknown threads to a
>
>
>> process. :-)
>
>
> If the userland doesn't know about them, how would it affect it?
I said it should be invisible to userland debugger, but ptrace interface
will expose it to userland, you have to calculate actually threads
number for PT_GETNUMLWPS, you also have to filter aio threads out for
PT_GETLWPLIST, you also have to figure out first threads which is
meanful to userland for PT_LWPINFO, others I don't know yet.
I didn't say that injecting unknown threads into process is not
practical, but it should be carefully to not break current stable code.
> As a kernel thread it wouldn't take part in signals, other than to abort
> when the process exits.
Also, process suspension should suspend these aio threads.
> it WOULD accumulate cpu time for the process.. but that is just fair.
> currently I think that
> aio is "free".
>
Yes, you are right.
> Anyhow I'm not ready to try do it now.. As the current patches leave the
> status-quo for aio.
>
>
OK.
>
>
>
>
>
>> I still prefer current model, also the aiod threads can be reused for
>> multiple
>> processes.
>
>
> that is both a positive and a negative when it comes to accounting.
>
>
>
More information about the freebsd-current
mailing list