Date: Tue, 24 Jan 2006 10:24:54 +0800 From: David Xu <davidxu@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org Subject: Re: kernel thread as real threads.. Message-ID: <43D58FF6.6050605@freebsd.org> In-Reply-To: <43D57BDF.6010308@elischer.org> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <43D5753D.8060102@freebsd.org> <43D57BDF.6010308@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D58FF6.6050605>