Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About
 It?
Date: Tue, 13 May 2025 08:33:15 -0700
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vvvons$3uvs3$2@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 17:33:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0b46d86f60a4fea04db48bfec08a8d15";
	logging-data="4161411"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198M20RDjLfjO4KFNZm6bhok947NungSVM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:NBx5KWB0OKHob6RVvJEaj4J43Pw=
Content-Language: en-US
In-Reply-To: <vvuuua$1mt7m$1@dont-email.me>
Bytes: 4068

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.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)