Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Jun 2001 09:59:26 -0700 (PDT)
From:      Richard Hodges <rh@matriplex.com>
To:        Christopher Sedore <cmsedore@mailbox.syr.edu>
Cc:        Josh Osborne <stripes@mac.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: question: aio / nbio / kqueue
Message-ID:  <Pine.BSF.4.10.10106250858280.72662-100000@mail.matriplex.com>
In-Reply-To: <Pine.SOL.4.10.10106250822410.3561-100000@rodan.syr.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10106250858280.72662-100000>