[Info-vax] What would be involved in moving RMS into kernel mode ?

[Jan-Erik Söderholm]

Den 2023-05-06 kl. 05:26, skrev Hein RMS van den Heuvel:
> 
> Chris Townley>> I am sure Hein is available
> 
> Nah, happily retired.
> 
> On Friday, May 5, 2023 at 6:19:10 PM UTC-4, Stephen Hoffman wrote:
>> On 2023-05-05 12:22:56 +0000, Simon Clubley said:
>>
>>> On a more serious note, I've received private email pointing out that
>>> there may be an issue with PPFs if running RMS in user mode.
>> User mode in a different process is (ideally) immune to user mode
> 
> PPFs would be challenging. Executing RMS in a slave process - dedicated or shared - could solve a lot.
> One could perhaps also think of a hybrid solution where usermode is used wherever possible but when for example the PPF flag is seen in the IFI/ISI a dive into the normal exec mode RMS is made .
> 
>>> I also wonder how global buffers might be affected by user-mode RMS.
>> Either the buffers are mapped and accessible in virtual memory, or not.
> 
> Global buffers can be mapped in usermode, the penalty for a bad actor would get magnified as it could kill an unsuspecting other process, which is why I also indicated them as potentially challenging. There is currently also a global buffer lock optimization implemented with system lock. That particular optimization is an enormous win in simple 'get next' processing and cache hits. without that (pre 7.3), every entry into a buffer would at lease convert a lock to up, and down again on exit. with the optimization the system lock guarantees that the right version of bucket data is in the buffer. That is a massive locking (and thus kernel mode or even MPsync time)  win.
> 
>   
> Hoff> And there's an open question around how beneficial RMS global buffers
> Hoff> might be in practice, given current SSD transfer speeds are approaching
> 
> Indeed. But that lock optimization I just mentioned is nowadays more important with the caching XFC and faster and faster (caching) IO, for that alone global buffers as a big win.
> 
> Hoff> But again, VSI is not in a position to re-architect OpenVMS now, nor in  the forseeable future.
> 
> Correct.
> 
> Also, we just don't know yet where we are whether there is a problem big enough to worry about.
> Brute power may well come to the rescue. Let's wait and see the results when X86 VMS is build with optimizing compilers before speculating about the need for a solution.
> 
> Some places (C-RTL, COBRTL, SORT) already use their own usermode code avoiding SYS$GET, SYS$PUT for simple unshared sequential files for that very performance reason of avoiding the CMEXEC and PROBES. But for those simple files that overhead is disproportional as they pretty much deal with 1 known buffer of data and a predictable offset in that buffer. Once one gets into indexed file territory the actual work grows a lot often involving multiple buffer visits and buffer searches. With that the the entrance price into the service becomes relatively much less important than work performed for the service.
> 
> Cheers,
> Hein.
> 
> 

About RMS Global Buffers. What files are these usually used for?
I have got an (maybe wrong) impression that it is mostly indexed
files "databases".

As an example, Rdb is not using RMS for the data/storage. It is
used for some Rdb files like the backup files and "export" files,
but for that I do not see can gain much from faster global buffers...