[EMAIL PROTECTED] wrote:
Another reason why interrupts are expensive is context switching, which
means a set of code entirely different from what was executing suddenly starts
executing. Thus all the high-speed buffers used in instruction fetching and
processing (instruction pipeline and translation look-aside, e.g.) will have
many misses for a while, and the code that processes that particular type of
interrupt may need to clear the buffers that are clearable via software. This
context switching causes a significant degradation in instruction execution
time, and it is large enough that IBM invented at least one new instruction
(Test Pending Interrupt) and add several functions (IOS uses TPI and SRM
enables/disables CPUs for I/O interrupts) into MVS in order to reduce the effect.
re:
http://www.garlic.com/~lynn/2007c.html#45 SVCs
As an undergraduate in the 60s ... for cp67, i had also done a lot of stuff
with dynamic adaptive resource management and page replacement algorithms ...
separate from the pathlength stuff.
for some topic drift ... some old email related to page replacement stuff
http://www.garlic.com/~lynn/lhwemail#globallru
including this bit involving big uproar and opposition to granting somebody a
Phd from Stanford ... effectively about stuff that I had done more than ten
years earlier as an undergraduate
http://www.garlic.com/~lynn/2006w.html#email821019
in this post
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After
Multi-Core
and of course lots of past posts mentioning page replacement stuff
http://www.garlic.com/~lynn/subtopic.html#wsclock
I even had something of a set-to with the POK performance modeling group on the
subject during the early days of SVS development ... and some choice they made
for page replacement ... which took nearly five years ... well into MVS
releases ... before they could understand how really bad the design choice was.
In any case, a lot of the work I did as an undergraduate on cp67 was dropped in
the morph to vm370. I was given an opportunity to re-introduce the changes as
the vm370 resource manager. And to get back somewhat on topic ... the resource
manager had some dynamic code deciding on whether to dispatch virtual address
spaces enabled or disabled for I/O interrupts ... in order to minimize the
effect of context switch on cache hit ratios (long before MVS was doing it).
lots of past posts on dynamic adaptive resource control, fairshare scheduling
and resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
So the 360/67 functional specification (of bitsavers) lists 3.75mics for the
SVC instruction and 3.95mics for the SVC interrupt ... assuming this are
actually different and not included as a subset/superset of the other ... then
the aggregate is nearly 8mics.
So the equivalent might be a SSM instruction (going from disabled to enabled)
plus an I/O interrupt. Time for an I/O interrupt is listed as 4.65 mics and the
time for SSM is 4.16 mics ... aggregate of nearly 9mics.
So my resource manager actually did two things ... 1) after running in the hypervisor
disabled for i/o interrupts ... and just before the dispatcher was going to choose the
next task to run, load up all the registers and and stuff ... it would do a pair of SSM
instructions to enable/disable for interrupts. Basically any pending I/O interrupt was
giving a chance to "interrupt" ... in the interrupt window ... and skip all the
wasted overhead of attempting to dispatch another task ... and 2) dynamically decide
depending on interrupt rate ... whether to run task enabled or disabled for i/o
interrupts. This was on 370 w/o any special new instructions.
Somewhat related posts about doing internal operating system distribution on
vm370 for internal distributions (including lots of stuff other than what was
chosen for release as the resource manager) ... including some old email
http://www.garlic.com/~lynn/lhwemail.html#1973
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
so for other topic drift ... unbundling was announced on 23jun69 ... starting
to charge for application software ... instead of all software being free.
however, there was an argument used to leave kernel software free (i.e.
bundled) ... because it was required for operation of the hardware. However, by
the time it was decided to release the resource manager ... things were started
to shift towards wanting to charge for kernel software only ... and the
resource manager got chosen to be the guinea pig ... so i got to spend a lot of
time with the business people working on policy for charging for kernel
software. lots of past posts mentioning unbundling and the transition to
charging for software
http://www.garlic.com/~lynn/subtopic.html#unbundle
Now some additional topic drift about context-switch and cache hit ratios (this wasn't issue on 360/67
because it didn't have processor cache). Now while Charlie had invented the compare&swap instruction
(compare-and-swap mnemonic was chose because CAS are charlie's initials) doing a lot of work at the science
center on multiprocessor support for cp67 on 360/67 .... vm370 didn't ship with support for multiprocessor
operation. Further topic drift, POK owners of 370 architecture actually rejected compare&swap instruction
for 370 architecture ... saying that a new "multiprocessor" instruction was required (test&set
was sufficient). In order to get justify compare&swap instruction for 370 ... uses other than
multiprocessor specific operation was needed. Thus was born that whole programming notes how applications
enabled for interrupts can use compare&swap instruction for atomic operations (regardless of whether
running in multiprocessor or not). Lots of past posts on multiproces
sor operation and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp
So for the vm370 release after the resource manager shipped ... it was decided
to put in vm370 multiprocessor operation. I had done a lot of work in this area
... and in fact, the resource manager had a bunch of code included related to
vm370 kernel code restructure for supporting multiprocessor operation. In any
case, the multiprocessor support that shipped in the next release of vm370 was
structured that it tended to keep a task running on a processor helping promote
improved cache hit ratio (w/o having explicit code that looked at cache
affinity ... it just fell out of how the code executed ... I use to make
comments that best fastpath was not having to explicitly execute any code at
all, let it be 2nd order side effects of how other code executed ... however,
such stuff made for problems with long term maintainability).
So standard 370 cache machines slowed down machine cycle by ten percent for two-processor operation i.e. the effective hardware execution of two processor was 1.8 times a single processor ... after throwing in multiprocessor software overhead ... standard claim was that two-processor tended to have thruput of around 1.5times a single processor. However, because of the way the original vm370 multiprocessor dispatching tended to work ... there was sometimes where two-processors operation was getting more than twice the mip rate of a single processor (even tho the hardware cycle was only 1.8 times because each processor running at .9 times) on same workload ... because of the way cache hit stuff was happening.
So the other problem with vm370 resource manager and the initial release of vm370 multiprocessor support had to do with unbundling. Policy decision at the time for charging for kernel hardware was that if it was directly involved in supporting hardware ... which multiprocessor support was ... it was still to be free. The problem was that vm370 multiprocessor support had big dependency on the kernel restructure that had already been shipped in the vm370 resource manager for the prior release. It would be violation of the policy to have "free" hardware support dependent on a component that was charge for. So the decision was made to remove about 70-80 percent of the code from the resource manager and merged it into the "free" base system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
