Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Date: Sat, 31 May 2025 12:53:59 -1000 Organization: Wheeler&Wheeler Lines: 57 Message-ID: <87y0uc8k8o.fsf@localhost> References: <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org> <2025May13.094035@mips.complang.tuwien.ac.at> <100oetb$c5c7$1@paganini.bofh.team> <100q47d$3k7s2$1@dont-email.me> <100srqk$pos5$1@dont-email.me> <100vm4s$16av3$1@paganini.bofh.team> <100vq44$1h5c4$1@dont-email.me> <1012euo$1fclb$1@paganini.bofh.team> <1012lf9$23l9t$2@dont-email.me> <101b2dk$4vts$2@dont-email.me> <101b8ei$a20i$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 01 Jun 2025 00:54:03 +0200 (CEST) Injection-Info: dont-email.me; posting-host="981b58e503d81f295056360e179ec8fc"; logging-data="1597320"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+5k0bZE4bYS4fx8ZSn3hqMPPWRZDQp2CQ=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:HN4HPHTTGXzMKfA1si/a1FfzK0Y= sha1:PdIH0U+cgGBdkgfgwpD2PPWUrFo= Xref: csiph.com comp.arch:111909 Stephen Fuld writes: > I was too flip in my answer, so here is, I think, a better one. The > "it" to which we are referring here is caching of write data. > > So let's look at a possible scenario. Let's say the heads are at > cylinder 100. A write comes in for data that is at cylinder > 300. Without write caching, the disk will move the heads to cylinder > 300. Now lets say the next request is a read for data at cylinder 150. > If the write had been cached, the disk can handle the read with only a > 50 cylinder move, then the write with a 150 cylinder move for a total > of 200 cylinders. Without write caching, the first move is 200 > cylinders for the write, followed by 150 back for the read for a total > of 350. Thus the read data, which is presumably more time critical, is > delayed. > > Overall, write caching improves performance, but if you don't want it, > then you can essentially not use it, either by forcing the writes to > go to the media, or not using command queuing at all. Early 70s, as mainstream IBM was converting everything to virtual memory, I got into a battle. Somebody came up with a (LRU?) page replacement algorithm that would replace non-changed pages (didn't require a write before the read replacement) before changed pages (which needed a write before being able to fetch the needed page). Nearly a decade later, they finally realized that they were replacing highly used, highly shared RO/non-changed pages ... before replacing, private, single-task, changed data page (before they realized it was possible to keep a pool of immediately available, changed pages that had been pre-written). ATM financial started using the IBM (airline) TPF operating system ... light-weight but had simple ordered arm queuing algorithm for reads/updates/writes. Then a little later in 70s an IBM tech in LA at a financial institution redid it looking at ATM use history and anticipating account requests (that would result in reads/updates/writes ordering that hadn't happened yet). Under heavy load, it improved aggregate throughput (and under lighter load it make little difference) ... sort of delaying a 300cyl seek anticipating likelyhood of transaction (as yet to happen), that would involve a shorter seek. since sometime in the 80s, (at least) RDBMS have been using "write caching" (write behind) where the sequential log/journal of "committed" transactions is made and actual RDBMS writes happen in the background. Failure recovery requires rereading the log and forcing pending writes for committed transactions. Originally in cluster environment, any (RDBNS) pending writes for transaction lock request from a different system would force pending writes before granting a different system the requested lock. I did a hack where I could append queued/pending writes to passing the transaction lock to a different system ... in the era of mbyte (shared, multi-system, cluster) disks and gbyte interconnect. -- virtualization experience starting Jan1968, online at home since Mar1970