Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jun 2001 20:44:17 -0400
From:      Josh Osborne <stripes@mac.com>
To:        Richard Hodges <rh@matriplex.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: question: aio / nbio / kqueue
Message-ID:  <200106230044.RAA18157@smtpout.mac.com>
In-Reply-To: <Pine.BSF.4.10.10106221717070.63905-100000@mail.matriplex.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[...]
>> AIO is good when you are not receiving much data (or not receiving
>> it very frequently), and presumably want very low latency.
>
> What if you want good performance with "moderate" disk IO, say ten
> to twenty megabytes per second continuously?

I don't know if select/kqueue/poll "work" on normal files under
FreeBSD (the docs for kqueue on 4.3 seem to say it has the
"traditional" behavior of always saying a file is ready, at
least if you aren't at the end)

BSD/OS had select working for FFS files (returns ready to read
if the block the file pointer is at is in the buffer cache, and
sends a read ahead request).  Or at least they (Paul?) calmed
they did, I never tested it.

> 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.

I try to avoid anything that makes me write signal handlers (AIO
is done with signals, right?), and doing a ton of data block after
block doesn't sound like AIO's bag anyway.  Maybe you missed the
AIO signals by failing to properly do some mystical signal ritual.
Maybe there is a kernel bug.

> Is there any better solution than just forking off a process for
> each file and letting the kernel handle the details?

Depends, is kernel hacking strictly off limits?  From my point
of view that would be ideal because I would get the benefit of
your labor :-)

If you do have to fork child processes, using sendfile (unportable)
may well have pretty low overhead.  It is documented as zero copy.
I would give that a shot.

Note: my current spare time project is currently just forking
and execing cat, so take my advice with a grain of salt :-)
Of corse that project only needs about 196Kbits/sec of bandwidth
anyway...
--
Not speaking for my employer
Barely speaking for myself

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?200106230044.RAA18157>