Performance and Capacity Planning 737

re:

when i was an undergraduate ... i did a lot of path rewrites of stuff that i thot would likely be high-use ... as well as doing "fastpath" ... special case path thru the code for the most common case. some of that reduced pathlength by factor of 100 times ... and for some general benchmarks ... overall reduction of 80-90 percent. old reference to presentation at gave at boston share, aug. of 1968:

for ecps ... thet i was doing concurrently with vamps ... there was extensive instrumentation for what parts of of kernel to drop into microcode of th (uniprocessor) virgil-tully machines. here is summary of one of the studies

basically we were told that there would by 6000 bytes of microcode for ecps (vm microcode performance buttist) .... that kernel type cp code would drop aaproximately byte-for-byte from 370 code into machine microcode ... and that machine micrcode would run about ten times faster than 370 code (i.e. the native machine micrcode engine had about a 10:1 instruction ratio emulating 370 ... so dropped directly into microcode).

in the vamps scenario, it was slightly more structured than in the ecps scenario ... where everything was a candiate. in vamps there was some logical construction limitations ... i.e. where in the processing path the code actually was.

the top two pathlengths in the ecps study (referenced above), i had extensively optimized repeatedly over the years ... and they still accounted for 15 percent or so of kernel time ... and they were also in area that could also be placed for vamps.

the top item is selecting a virtual machine to run ... loading up all the information for running that virtual machine ... and then dispatching the virtual machine. with the queued interface for vamps ... the kernel just put tasks on queue for dispatching. the processor microcode selected something on the dispatch queue, locked the queue entry, loaded up the information to run ... and ran it.

the 2nd entry (in the ecps study) was entry to the kernel typically because of 1) page fault or 2) privilege instruction interrupt ... requiring the kernel to simulate on behalf of the virtual machine. in both vamps and ecps ... some amount of the microcode involved in end of privilege instructions ... was enhanced to recognized "virtual machine" mode ... and as a result would directly execute a "privilege" instruction using "virtual machine" rules ... bypbutting having to enter the hypervisor kernel for simulation of the privilege instruction. for other things that actually required entry into the hypervisor kernel, the vamps code would directly handle a lot of the status storing away and attempting to obtain the kernel lock ... and actually entering the kernel. If the vamps microcode was block from entering the kernel ... it would queue a super light-weight task against a kernel queue ... and go off to the (microcode) dispatcher to run another task.

from the kernel standpoint ... it saw putting things on a queue ... and re-entry as part of pulling something off the queue. it never actually saw low-level interrupts ... typical of real 360-370 ... and-or spinning for a kernel lock; a processor either entered into kernel mode (because no other processor was currently in kernel mode) ... or it queued a request for kernel mode and went off to see if there was other (non-kernel) work to do.