Date: Mon, 25 Jun 2001 13:40:00 -0400 (EDT) From: Christopher Sedore <cmsedore@mailbox.syr.edu> To: Richard Hodges <rh@matriplex.com> Cc: Josh Osborne <stripes@mac.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: question: aio / nbio / kqueue Message-ID: <Pine.SOL.4.10.10106251331210.3561-100000@rodan.syr.edu> In-Reply-To: <Pine.BSF.4.10.10106250858280.72662-100000@mail.matriplex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You might try using aio_waitcomplete instead of aio_suspend. I wrote it because I hated the aio_suspend/array methodology. You should also make sure you bzero the aiocb structure before use as some of the fields could cause strange behavior if left with random data. -Chris On Mon, 25 Jun 2001, Richard Hodges wrote: > > On Fri, 22 Jun 2001, Richard Hodges wrote: > > > > I tried AIO some months ago (4.1R or 4.2R), but had some trouble > > > with AIO, mainly that it seemed to lose track of half my files. > > > Not any particular files, it seemed that at any moment it would > > > just pick ten or so (out of maybe 20-25 files) to ignore at any > > > given time. > > > > > On Mon, 25 Jun 2001, Christopher Sedore wrote: > > > I've done this at the 3-6 MB/sec continous (peaks at 10MB+/sec) range with > > good success with aio, both the network and disk functions. Never had > > trouble with it losing track of files (not sure what you mean here). If > > you didn't tweak some of the default sysctl settings, you may have bumped > > limits that caused unexpected behaviour (though you should have gotten > > error returns to let you know). > > Going back to my notes, my first use of AIO was: > > For every file to read: > 1. Clear aiocb and fill all fields, > x->aio_sigevent.sigev_notify = SIGEV_NONE; > x->aio_sigevent.sigev_signo = 0; > 2. Do an aio_read(), if no error, put pointer to aiocb > into an array > 3. Do aio_suspend with pointers to the successful > aiocb's from the aio_read()'s > > The idea is to queue up the requests and wait for one of them > to succeed. Then check all of the files, for each pending: > > 4. Get status with aio_error() > 5. If EINPROGRESS, check next file > 6. If zero or error, get status with aio_return > 7. If successful, log new data and check next file > 8. If error, log error and check next file > > What I found out that aio_suspend() will fail with a rather low > number of file operations (AIO_LISTIO_MAX==16), so aio_suspend() > is not an option. > > So instead of doing aio_suspend(), I had a loop that posted > new reads as neccessary with aio_read(), and another loop > that checks each pending operation with aio_error(). This > allowed some of the reads to succeed, but for some reason > AIO seemed to forget about some of them, as if AIO has some > internal limit to the number of pending read operations. This > was with only 20 files, and reading from UFS on vinum (striped). > > This was about half a year ago, but I am sure this is reasonably > close to what really happened... > > -Richard > > ------------------------------------------- > Richard Hodges | Matriplex, inc. > Product Manager | 769 Basque Way > rh@matriplex.com | Carson City, NV 89706 > 775-886-6477 | www.matriplex.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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?Pine.SOL.4.10.10106251331210.3561-100000>