UNIX semantics do permit full support for asynchronous I/O

John Chambers jc at minya.UUCP
Mon Sep 3 06:18:45 AEST 1990


In article <BZS.90Aug31173255 at world.std.com>, bzs at world.std.com (Barry Shein) writes:
> 
> Do there exist any benchmark or other test results which indicate that
> adding asynch i/o to unix actually yields a performance improvement?

Well, I don't have the papers any more, and in any case, they were internal
documents at the compnay I was working for, but I did a study along this
line about 5 years ago.  We used an assortment of Sys/V, Sys/III, and BSD
systems, including a couple (e.g., Masscomp) that implemented contiguous
files.  I wrote a set of test programs that did various patterns of file
access (sequential, random, random-followed-by-sequential, etc.), and also
tested a number of the companies' existing applications.  Files were opened
with/without O_SYNC, and were contiguous/allocated on different tests  The
tests were run both alone and together with other applications, giving a
total of 8 combinations for each test, which were run long enough to give
stastically-significant results.

The results were disappointing for those that wanted these features.  Most
of the tests showed no significant differences among the combinations.  In 
the few cases where there was a difference, the "normal" case (no syncing,
not contiguous) was the winner by a small margin.

It was particularly interesting that we couldn't find a single application
that ran faster with contiguous files than with normal files.  I'm sure
that some exist, but we couldn't construct them.  I was less surprised that
automatic syncing didn't benefit anyone; I had predicted that.  After all,
forcing a block to be written causes it to be marked "clean", so it becomes
a good candidate for re-use if buffer space is low.  As a result, such files
tend to have a somewhat smaller fraction of their data in buffers, so random
reads are somewhat less likely to have a hit.  It's not big, but for random
I/O, it is measurable.

It'd be interesting to hear of cases where these features are worth their
price (in kernel code, programmer time, etc.).



-- 
Zippy-Says: Imagine ... a world without clothing folds, chiaroscuro, or marital difficulties ...
Home: 1-617-484-6393 Work: 1-508-952-3274
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Uucp-map: minya	adelie(DEAD)



More information about the Comp.unix.wizards mailing list