From owner-freebsd-hackers Mon Jun 25 10:40:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by hub.freebsd.org (Postfix) with ESMTP id ED94F37B401 for ; Mon, 25 Jun 2001 10:40:01 -0700 (PDT) (envelope-from cmsedore@mailbox.syr.edu) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.001E7F3E@mailer.syr.edu>; Mon, 25 Jun 2001 13:40:01 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id NAA12619; Mon, 25 Jun 2001 13:40:00 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Mon, 25 Jun 2001 13:40:00 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: Richard Hodges Cc: Josh Osborne , freebsd-hackers@FreeBSD.ORG Subject: Re: question: aio / nbio / kqueue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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