Date: Mon, 23 Jan 2006 18:35:04 -0800 From: Julian Elischer <julian@elischer.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: kernel thread as real threads.. Message-ID: <43D59258.1060705@elischer.org> In-Reply-To: <20060124011243.GT25397@cirb503493.alcatel.com.au> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <20060123224756.R48094@fledge.watson.org> <43D56468.1060101@elischer.org> <20060123232836.M48094@fledge.watson.org> <43D56E79.60504@elischer.org> <20060124011243.GT25397@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: >On Mon, 2006-Jan-23 16:02:01 -0800, Julian Elischer wrote: > > >>>And any others I don't remember. We may find we need to perform an >>>aio drain wait there if we switch to doing AIO in the process context. >>> >>> >>I don't think so.. >>IO is really 2 stage: >> >>for read, data is read into the cache by standard async kernel code. >>then the thread wakes up and writes it to the user space. >>if the thread has died the async request is still allowed to complete. >> >> > >Is this done as a one-off event, or will data be copied from kernel >to userland as the data arrives in the kernel? The former implies >that the userland buffer is (pretty much) atomically updated - it is >unchanged until all the available data arrives, at which point it is >all copied into userland and the aio flagged as complete. The latter >implies that parts of the userland buffer will update gradually. The >difference primarily affects large requests (and the latter approach >implies that less kernel resources will be tied up by the I/O). > > I sugest reading the code.. I don't know the answer.. But I'm interested to hear the answer. I believe it's done in (largeish) chunks but I may be wrong. :-) >What about the write case? > > I believe it's symetrical with read., In either case. If the requestor is not around at completion of the physical IO it is not much of a problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D59258.1060705>