Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!decwrl!bacchus.pa.dec.com!decvax.dec.com!ima!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.wizards Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: <439@minya.UUCP> Date: 2 Sep 90 20:18:45 GMT References: <60345@lanl.gov> <27619@nuchat.UUCP> Distribution: usa Lines: 42 In article , bzs@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)