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

[Simon Clubley]

On 2023-05-07, Johnny Billquist <bqt at softjar.se> wrote:
> 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.
>

To read 5,000 records using RMS from a user-mode program requires 10,000
TLB invalidations unless there are any hardware shortcuts available. Have
a think about the implications of _that_ :-)

Fortunately, Intel has such a shortcut available in the form of the PCID
functionality. If used properly, this is supposed to reduce the number
of required TLB invalidations down to a _much_ more reasonable level.

However, until recently, AMD processors did not have PCID support.
Given that VSI have added support for AMD processors, that is why I was
interested in seeing the performance numbers on an AMD box without PCID
support.

The kind of numbers that Mark is reporting on an Intel machine with
PCID support are the kind of numbers I was expecting to see on an older
AMD box without PCID support.

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

Actually I do. It's just that I appear to be ahead of you.

>>> 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).
>

The emulation is the switching out of page tables in the 2 available
hardware modes to emulate the missing executive and supervisor modes.

>
> 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.
>

Code running in those emulated modes runs at the same speeds _once_ you
are in that mode. However, what about the overhead of getting in and out
of those emulated modes ?

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.