[...]
>> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
