[Info-vax] OS implementation languages

[Johnny Billquist]

On 2023-08-31 21:12, Bob Gezelter wrote:

> Johnny,
> 
> You are correct that much of the I/O plumbing is highly similar in RSX and VMS, and for that matter WNT. A case of common authorship.

Yeah... :-)

> To understand the issues fully, one has to think not just linearly, but also carefully consider the timeline and other time-related issues. There are many conceptual traps.

True.

> However, file I/O has an explicit serialization: virtual to logical block mapping. The original I/O packet is reused iteratively to process the potentially discontiguous logical blocks required. This imposes a serialization that is not conducive to performance. There is an extended description and analysis in my dissertation/monograph; a somewhat abbreviated version of which is in the previously referenced IEEE conference paper.

In RSX atleast, this isn't neccesarily true. Both with FCS and RMS, they 
offer the capability of read-ahead in a completely transparent way for 
the application. And they do this by issuing multiple QIO in parallel, 
so there are multiple I/O packets in flight.
But the mapping between virtual and logical blocks are happening in 
F11ACP, which is a chokepoint. But because of this, for an open file, 
the mapping from virtual to logical blocks can actually happen in the 
kernel without involving the ACP, when the mapping is already in memory. 
So the first read will stall until the mapping have been read in, and 
then continue finding the translation and issuing the read of the proper 
logical block. The next I/O that comes right on the heels of the first 
one (as well as the third) will hopefully do the translation without any 
I/O involved, and the read for the correct logical block will be queued 
up to the driver before anything have been completed. And then the 
driver immediately places the requests on the queue of the controller, 
who then can both work on doing them in the optimal order, and the 
completion is going to happen in some random order. However, as soon as 
the read for the first virtual block is completed, FCS (or RMS) will 
return operation to the program that is reading the file. Meanwhile in 
the background, while the program is operating, the other I/Os will also 
eventually complete, so by the time the program's reading progress to 
those blocks, they are already in memory. And in the background, FCS (or 
RMS) will already have issued additional reads for more blocks while the 
program was doing its work.

But this is RSX. Details on how much of this also is done in VMS I don't 
know.

> If one looks for correlations of logical block requests, the most common correlations are requests to the same file on the same access stream. Ibid. Sequential reuse of the same IO packet prevents optimization within a request stream.
> 
> Hardware reordering can only reorder requests that are simultaneously outstanding. Ibid.
> 
> The RSX design was obligatory due to the then lack of system pool. Then, even individual IO Packets were precious. Correctness beats efficiency. For more than two decades, increases in memory capacity and non-paged pool expansion has rendered the memory minimization design goal quaintly anachronistic.

Well. Like I said above, RSX actually is somewhat eager to do this. 
Especially on 11M+, which do have a bit more resources available. In 
plain 11M, you didn't see this done as much, since resources were more 
scarce.

> The preceding is all in the reprint. A thorough reading of the referenced paper is highly recommended. When I can find the time to finish copy-editing the monograph and get it printed. I will note the general availability in a posting.

And if you want more deep diving into RSX, just let me know. I'll 
happily guide you through it. But it will be lots of MACRO-11. ;-)

   Johnny