On Wed, Apr 29, 2009 at 2:49 PM, Alan Altmark <alan_altm...@us.ibm.com> wrote:
> An unassisted SIE instruction is trapped by the underlying z/VM system and > "trimmed" to reflect what the underlying z/VM system knows about the guest > who issued the SIE. Then that underlying z/VM issues a SIE. With few > exceptions, all nth-level guests run under real SIE. Of course, you > haven't got much of a time slice and there are fewer guest pages resident > in SIE-accessible memory, so you don't stay in SIE very long. Hence the > poor performance. But while that guest is in SIE, he's running at full > speed. There are some kinds of pre/post-real SIE conditions that have to > be simulated by each underlying z/VM, so sometimes you never reach real > SIE. You need to know where to look to see spot the recognize the overhead. I'm not sure you're saying the same, but my experience is that the overhead is not because of the SIE instruction. Surely CP needs to massage the SIEBKs to get things right, but that's not the big cost. It's because of the reduced function of some things under V/SIE. With Linux running 3rd level for example, it appears the big hit is the way copy-on-write works in that you get a lot of program checks. As long as you don't go beyond the hardware support, the program check can be reflected to the guest itself. But with more levels of DAT stacked, the result is that first level CP has to emulate DAT as if we had no hardware support and do the shadow table smoke and mirrors by hand. So you should see overhead on the 1st level CP. 2nd level CP is unaware of what is happening and will merely assume CPU contention. I'd expect Berry to be more lucky with VSE maybe less heave do deliberate program checks, especially when VSE itself does not page. As always, one would need to look at real data... Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
