Path: ...!npeer.as286.net!npeer-ng0.as286.net!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!nntp.comgw.net!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: Mon, 19 May 2025 14:58:48 -0700
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <100g9ip$1otvf$1@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> <vvvons$3uvs3$2@dont-email.me>
 <1000nfp$2440u$1@dont-email.me> <1000pae$3uvs3$3@dont-email.me>
 <100bdhq$lhdb$3@dont-email.me> <87sel1jw9z.fsf@localhost>
 <100e28i$11n5t$1@dont-email.me> <100g5an$1q32t$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 May 2025 23:58:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e34e850295942d1c999e7ca5a25626c";
	logging-data="1865711"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191w29+PfIejc69f1J9JSwAJRaPGDzRBSM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FL2PClTiEYr3IBGS62wkmkUY/g4=
Content-Language: en-US
In-Reply-To: <100g5an$1q32t$1@dont-email.me>
X-Received-Bytes: 2845
Bytes: 2972

On 5/19/2025 1:46 PM, Vir Campestris wrote:
> On 19/05/2025 02:41, Stephen Fuld wrote:
>>
>> It didn't make sense to, after executing the full track read, since 
>> the disk was positioned at the end of the track, and you had a good 
>> indication that it was a sequential file read, to start caching the 
>> next track in anticipation of the next full track read?
> 
> It might if the disk was idle. But if there is a queue from another 
> process it probably will be better to do that instead.

I presume you know that the 3880 controller did not do what today we 
call command queuing, so I think you were referring to a potential queue 
in the host.  That being the case, the controller doesn't know if there 
is a queue or not.  So given that, why not start reading record 1 on the 
next track.  If a request comes in, you can abandon the read to service 
the request - no harm, no foul.  If there isn't, and you subsequently 
get a request for that track, it's a big win.  The only potential loss 
is if you get a request for the track that was LRU and got pushed out of 
the cache.


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