From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 02:24:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A59DC16A420; Tue, 24 Jan 2006 02:24:46 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FED943D48; Tue, 24 Jan 2006 02:24:46 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0O2OhqW065261; Tue, 24 Jan 2006 02:24:45 GMT (envelope-from davidxu@freebsd.org) Message-ID: <43D58FF6.6050605@freebsd.org> Date: Tue, 24 Jan 2006 10:24:54 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <43D5753D.8060102@freebsd.org> <43D57BDF.6010308@elischer.org> In-Reply-To: <43D57BDF.6010308@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel thread as real threads.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 02:24:46 -0000 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. > > >