Performance issue in z/Arch architecture mode (visible under SIE)

[ivan-w]

Running the actual same REXX program under CMS (ESA architecture) and z/CMS (ESAME) yield a more than 2 times performance degradation.

******************
i zcms
z/CMS V6.3.0   2018-08-17 16:08

DMSACP723I T (592) R/O
Ready; T=0.07/0.09 02:42:57
toto
Ready; T=69.01/69.14 02:44:09
i cms
z/VM V6.3.0    2018-08-17 16:08

DMSACP723I T (592) R/O
Ready; T=0.04/0.05 02:44:24
toto
Ready; T=29.52/29.58 02:44:55
******************

  toto exec a:

/* rexx */               
Z=0                
DO I = 1 TO 1000000
  Z=Z+I            
END 

A completely trivial test...

I will investigate this further...   (is it a SIE issue? is it a z/Arch issue?)

[Fish-Git]

... I also have an application that runs full time in z/Architecture mode with DAT on...

Which would not be impacted.

The bug (and my patch to fix/workaround it) only affects z/Arch guests which run real (i.e. with DAT mode off), like CMS and zCMS.

In any case, everything seems to be working fine with the patches.

Thanks! Appreciate the confirmation.

p.s:

... that creates a S/370 virtual machine for the purpose of running S/370 OS'es in a z/VM virtual machine.

COOL! Did you you write it yourself? Where did you get it? I would very much like to see (have) such a thing! It sounds very cool.

[ivan-w]

Bob's work is actually quite impressive.. I tried it, and it DOES allow one to run VM/370 under z/VM.. For what I understand it is all his own work !

[wably]

@Fish-Git: Actually I spoke partially incorrectly. My application runs the guest OS full time in z/Architecture mode with DAT on, however when the application is running internal housekeeping (such as simulating a S/370 privileged instruction, or updating its DAT shadow tables) it runs z/Architecture mode DAT off.

As for the application, yes I did write it entirely myself and it is all my own work. Its purpose is to be able to run VM/370 or VM/SP in a z/VM virtual machine. It can run MVS 3.8 under z/VM as well. It can also run natively directly on Hercules and run these guests although but that isn't really the intended purpose.

[Fish-Git]

Wow! I guess I'm going to have to put more effort in trying to get issue #87 resolved! ;-)

[Fish-Git]

Its purpose is to be able to run VM/370 or VM/SP in a z/VM virtual machine. It can run MVS 3.8 under z/VM as well.

Cool! I presume it can run e.g. DOS/VS(E) under z/VM as well?

[wably]

I'm not a DOS person, but my understanding is that the versions you mentioned use 2K page frames. This is not supported in the S/390 or z Architecture, so there is no way to properly shadow those pages if they are in non-contiguous page frames, which is very likely.

Therefore, unless you know that they use 4K pages the answer is no. This also precludes using OS/VS1 as well, which is definitely a 2K page frame system.

[ivan-w]

Most 2K systems (like VM/370 and DOS/VS) can be coaxed into using 4K page systems by feeding them a patched CR0 (turning SSK into SSKE). Of course, if they ACTUALLY rely on 2K pages (not on 2K page protection key) it's going to fall short.

[Fish-Git]

Fix (workaround) committed:   4998c658b38731fb7e74ff54aa66e9fa4521f0f8

Will keep this issue open for a while longer yet as previously agreed.

Thanks everyone!!! :)))

[ivan-w]

Fish,

I'm afraid you have the DAT refactoring backwards! The actual maddr_l function (code) should be in dat.h! (not dat.c!) And it should be static inline too (in dat.h), so every piece of code that does a MADDRL gets their own private inlined copy of the code.

The other functions currently coded in dat.h and guarded by #ifdef _DAT_C are the functions that should go into dat.c! Since they aren't declared static inline and only exist when #included from dat.c anyway (due to the #ifdef _DAT_C!), they can never be inlined anyway and they'll never be expanded by the compiler for any other .c file anyway (due to, again, the #ifdef _DAT_C!), so why not put them in dat.c since that's the only place they'll ever exist! (Afterall, what's the point of coding a function in a .h file if it only gets included from within a specific .c file?! Just put the darn thing in the .c file directly! Duh!)

Due to your change there is an approximate 20% reduction in performance on Linux.

If you concur, I can make the change.

[Fish-Git]

If you concur, I can make the change.

I concur! You are absolutely right, sir!

It was very silly of me to do it the way I did it. Your detailed explanation makes perfect sense! Please feel free to correct my gaffe at your earliest convenience.

p.s. My apologies for the 20% performance hit. I keep forgetting that gcc doesn't do global optimization like Visual C++ does, so I tend to not notice such things. Thanks for watching by back! Much appreciated buddy!

p.p.s. I also have a minor typo in dat.c on line 87 that's causing gcc to issue a warning (and in this particular case it's a very valid warning! A missing "*/" is usually a serious boo-boo that can easily break the code in a hard to detect manner!):

--- hyperion-1/dat.c    2019-08-18 16:16:10.000000000 -0700
+++ hyperion-0/dat.c    2019-08-19 12:16:08.645832200 -0700
@@ -84,7 +84,7 @@
             || (regs->AEA_COMMON( aea_arn ) & regs->tlb.common[ tlbix ])
         )
         {
-            /* Storage Key zero?
+            /* Storage Key zero? */
             /* Or if not, same Storage Key as before? */
             if (0
                 || akey == 0

Please feel free to go ahead and fix that for me too while you're at it!

Thanks!

[ivan-w]

Done & done! ;-)

[ivan-w]

This issue should now be confirmed as resolved. Closing