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: <vvnds6$3gism$1@dont-email.me> <edb59b7854474033c748f0fd668badaa@www.novabbs.org> <w32UP.481123$C51b.217868@fx17.iad> <vvqdas$g9oh$1@dont-email.me> <vvrcs9$msmc$2@dont-email.me> <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org> <vvribg$npn4$1@dont-email.me> <vvs343$ulkk$1@dont-email.me> <vvtt4d$1b8s7$4@dont-email.me> <2025May13.094035@mips.complang.tuwien.ac.at> <vvuuua$1mt7m$1@dont-email.me> <vvvons$3uvs3$2@dont-email.me>
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 <sfuld@alumni.cmu.edu.invalid> 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