Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

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