Date: Mon, 3 Jan 2000 21:27:58 +0100 (CET) From: Arjan.deVet@adv.iae.nl (Arjan de Vet) To: hackers@freebsd.org Subject: Re: AIO was Re: Kernel threads Message-ID: <20000103202758.8BC2822C5@adv.iae.nl> In-Reply-To: <Pine.SOL.4.05.10001031107090.6488-100000@luna.lyris.com> References: <007401bf561c$6ff51930$1e80000a@avantgo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.SOL.4.05.10001031107090.6488-100000@luna.lyris.com> you write: >> The best fix I've thought of thus far (other than async I/O, which I >> understand isn't ready for prime time) would be to have a number of kernel > >Speaking of AIO, which I would really like to use if possible, how >actively maintained is it? The copyright on vfs_aio.c is 1997, suggesting >to me that John Dyson has moved onto other things. Yep, that's right. Quite recently Christopher Sedore has done some work on vfs_aio.c, to make it work better with sockets and he also added a very useful aio_waitcomplete system call which returns the first aiocb (AIO control block) from the 'completed' queue. I would be nice if these patches could be added to FreeBSD-current. About AIO not ready for prime time: I did some experiments recently by throwing up to 256 aio requests on one fd (a raw disk device) into the system and it worked without any problems. The only time I got a panic was when (I think) I had a negative aiocb->offset (I still need to reproduce this). See http://www.iae.nl/users/devet/freebsd/aio/ for my aiotest.c program. I'm thinking about using AIO for a faster Squid file system by using raw disk devices instead of UFS which has too much overhead for Squid. Arjan -- Arjan de Vet, Eindhoven, The Netherlands <Arjan.deVet@adv.iae.nl> URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000103202758.8BC2822C5>