From owner-freebsd-current@FreeBSD.ORG Tue Jan 24 00:59:13 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 1A55016A41F; Tue, 24 Jan 2006 00:59:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB9CC43D48; Tue, 24 Jan 2006 00:59:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146]) by a50.ironport.com with ESMTP; 23 Jan 2006 16:59:11 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43D57BDF.6010308@elischer.org> Date: Mon, 23 Jan 2006 16:59:11 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <43D5753D.8060102@freebsd.org> In-Reply-To: <43D5753D.8060102@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; 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 00:59:13 -0000 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.