Date: Tue, 24 Jan 2006 12:12:43 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: kernel thread as real threads.. Message-ID: <20060124011243.GT25397@cirb503493.alcatel.com.au> In-Reply-To: <43D56E79.60504@elischer.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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). What about the write case? -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060124011243.GT25397>