Re: kernel thread as real threads..

From: Julian Elischer <julian_at_elischer.org>
Date: Mon, 23 Jan 2006 16:59:11 -0800
David Xu wrote:

> 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.
>>
> 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?
As a kernel thread it wouldn't take part in signals, other than to abort 
when the process exits.
it    WOULD accumulate cpu time for the process.. but that is just fair. 
currently I think that
aio is "free".

Anyhow I'm not ready to try do it now.. As the current patches leave the 
status-quo for aio.







> 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.
Received on Mon Jan 23 2006 - 23:59:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC