[Info-vax] OpenVMS async I/O, fast vs. slow

[Jan-Erik Söderholm]

Den 2023-11-07 kl. 01:18, skrev Arne Vajhøj:
> On 11/6/2023 6:31 AM, Johnny Billquist wrote:
>> On 2023-11-04 22:44, Arne Vajhøj wrote:
>>> On 11/4/2023 7:11 AM, Johnny Billquist wrote:
>>>> So how would memory mapped I/O be any faster? You basically cannot be 
>>>> any faster than one DMA transfer. In fact, with memory mapped I/O, you 
>>>> might be also hitting the page fault handling, and a reading in of a 
>>>> full page, which might be more than you needed, causing some overhead 
>>>> as well.
>>>
>>> Fewer layers to go through. More freedom to read ahead.
>>
>> Read ahead is something that the system can easily do both for normal I/O 
>> and memory mapped I/O. It's just a question of speculative reads assuming 
>> some pattern by the program. Most commonly that you are reading files 
>> sequentially from start to finish.
> 
> $QIO(w) and $IO_PERFORM(W) could.
> 
> But at least for $QIO(W) then I would be very surprised if it did. It is
> from before VIOC/XFC so originally it did not have anywhere to
> store read ahead data. VMS engineering could have changed
> behavior when VIOC/XFC was introduced. But I doubt it.
> 
> $IO_PERFORM(W) maybe. But I think the spirit is still
> "do exactly what the developer asked for and nothing more".
> 
> Arne
> 

And, of course, the "application" might do the prefetch.
Rdb has something called "detectable asyncronious pre-fetch"
that kiks in if Rdb detects that the user application fetch
database pages that are in sequence. It's on by default but
can be switched of if you do not think there is a benefit.
Such as if your I/Os are generally small and very random.