Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.arch Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Date: Fri, 23 May 2025 00:18:53 -0000 (UTC) Organization: To protect and to server Message-ID: <100oetb$c5c7$1@paganini.bofh.team> References: <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org> <2025May13.094035@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 23 May 2025 00:18:53 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="398727"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Bytes: 4604 Lines: 57 Stephen Fuld wrote: > On 5/13/2025 1:12 AM, Lawrence D'Oliveiro wrote: >> On Tue, 13 May 2025 07:40:35 GMT, Anton Ertl wrote: >> >>> In this case the drive knows things that the OS does not: Consider that >>> the OS asked for sector N what happens when the arm finally has settled >>> enough to read from the track, and the first sector it sees is sector >>> N+10. >> >> The OS isn’t likely to ask for one sector at a time. > > Frequently true, so consider this related scenario. The host requests a > read of 10 sectors starting at sector N. When the head settles, the > next sector is N+6. Without any in drive buffering, it would wait > almost a full revolution till record N comes under the head. > > With buffering, but no cache, the drive reads record N+5 to N+9 into the > buffer, then waits until the drive rotates to record N and begins the > host transfer. This is an improvement because the transfer to the host > is faster than the transfer from the disk, and the last 3 sectors can be > transferred out of the buffer without waiting for the disk, so the > transfer is completed faster. > > Now consider with caching. Similar, but after record N+9, the drive > continues reading into the cache. Lets say there are 30 records on this > track. If it reads all of the data into the cache, then proceeds as > above once the disk rotates to record N, it has cost zero time, and if > the host then issues another 10 sector read sequential to the initial > one (or actually any sectors from N+10 to N+29). This can be satisfied > out of the cache without any drive delay, so much faster than without > the cache, and the heads can be moved away to start satisfying another > unrelated request. There is minimal cost and substantial benefit. > > Now you have argued that the file system cache should take care of that, > presumably issuing prefetch reads for the next sectors. This will work, > of course, but has some disadvantages relative to using the drive cache. > Specifically,since it is unlikely the prefetch request will be > received by the drive before record N+10 has passed the heads, it will > incur additional most of a rotational delay, which will tie up the > drive, preventing it from responding to some other request. > > No one is arguing that host based file caches are bad. It is simply the > fact that there are situations where drive caches are a useful addition, > and since the drive has to have some DRAM anyway for other reasons, the > cost is minimal. You can think of the drive cache as the "next level" > cache behind the host based cache. It is pretty clear that due to drive mechanics track cache/buffer is useful. However, the real question is about size: how big should it be. For "consumer" drives I see claims of 256 MB cache. Given rather optimistic 200 MB/s transfer rate it is about 1.25s of drive data, that is 80-150 rotations. I would expect that say 4 tracks should be enough for reading. For writing one could use few more tracks. Still, advertised cache sizes seem to be much bigger than necessary. -- Waldek Hebisch