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

[Johnny Billquist]

On 2023-05-04 14:15, Simon Clubley wrote:
> On 2023-05-04, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2023-05-02 15:24, Simon Clubley wrote:
>>> If the emulated executive mode is a major reason for the kernel overheads
>>> we are seeing on x86-64 VMS, what would be involved in moving RMS from
>>> executive mode directly into kernel mode ?
>>
>> I have a hard time seeing why it would cost very much to deal with the
>> different modes.
> 
> In which case Johnny, you have no clue about the overheads involved here
> when emulating a processor mode in software.
> 
> I also suspect you have no clue either about why I keep asking about kernel
> overhead on AMD systems and what the significance of that question is.

And you'd be pretty wrong in your belief. I was maybe the only one 
around here that pointed out that it was absolutely possible and no big 
issue in running VMS on a hardware architecture that didn't have 4 
modes, when pretty much everyone around here claimed it was impossible.

So what overhead are we actually talking about? The different modes are 
really nothing more than a question of what protections to have on 
pages. The only mode that actually is special is kernel mode. The others 
have nothing more special than just a question of what protection to 
apply to the pages. There is not much "emulation" about it.

The biggest hit is that if you want that memory protection to apply, you 
need to use page tables with the appropriate protections for that mode. 
Which you'd probably solve by having multiple page tables, and you 
switch which page table to use based on the mode.

So the biggest hit is actually that you need to flush the TLB when 
switching modes, which comes with a bit of a cost since the TLB will 
need to be repopulated. But that is all done in hardware. So it comes 
with a cost, but not a huge one. Depending on the hardware, you might 
not even need to flush the TLB, since you are not actually changing any 
mappings, just changing the access rights for pages.


I get a feeling you still don't actually understand what the difference 
between the modes are, and what impacts this have.

>> I can definitely believe that code hasn't been
>> optimized in general, though.
>>
> 
> At best, that's only a small contribution to the numbers that Mark
> is seeing. Also, don't forget that the E/S emulation code is new code,
> not ported existing code.

There is not much emulation, as I point out above. I don't know what you 
think is going on, but it sounds like you think there is a lot more in 
there than there is (unless VSI did something really strange, which I 
doubt).

> A percentage is a ratio and unless there's any evidence that better
> compilers would affect the code running on one side of that ratio much
> more than the other side, then the overall percentage should still remain
> roughly the same even with better compilers.
> 
> I also note that VSI have not responded to Mark's question after the
> better part of a week. That's not a good look.

Code running in executive or supervisor would run at the same speed as 
code in any other mode. The CPU do not suddenly work in a different way 
in any of those modes. The only difference are what protection applies 
to memory pages. And that is a setup that happens at the mode switch. 
After that, it all runs just as normal.

   Johnny