Well done, Peter! Your details are a bit skewed, but you are on the right
track.
You've been paying attention in the IBM presentations, haven't you? ;-)
Your comments about the zAAP overhead resulting "from code in the JVM
needed to do the switching and of course from the context switch when going
to/coming from zAAPs" are right on! With some code, initially there were
hundreds of switches per second. One of IBM's performance improvements was
to change JVM so it could better decide whether a piece of JAVA code should
be "eligible to be shipped to a zAAP" or continue on a GCP. Kathy Walsh
(IBM WSC) discussed this switching issue in her Presentation "z990 and z890
zAAP - What it can do for you" at SHARE Summer 2004, Session 2825.
You did forget to mention the differences between whether zAAP-eligible
work would be dispatched on a GCP or zAAP, and when/why this dispatching
was done. Of course, the IEAOPTxx keywords help "control" where
zAAP-eligible work is to be dispatched. However, these controls with z/OS
V1R6 introduced many performance challenges (e.g., an unwelcome amount of
zAAP-eligible work would run on a GCP rather than a zAAP in certain
situations). To resolve these performance challenges, the "control" of
where zAAP-eligible work would run (GCP or IFA) radically changed with z/OS
V1R7; Alternate Wait Management was introduced into the algorithms and the
relative importance of IFACROSSOVER and IFAHONORPRIORITY essentially was
reversed.
You also implied that the JVM would continue managing the zAAP-eligible
piece of work on a zAAP until it gave up control. There also is the issue
of JVM recognizing that the work running on the zAAP needs services that
cannot be provided on a zAAP (e.g., I/O, or JNI call-back functions) and
return control to the Dispatcher so the work can be done on a GCP. As
mentioned above, IBM made changes to JVM to provide better algorithms that
consider the "microseconds per switch" value to guide whether a piece of
JAVA work should be classified as zAAP-eligible.
Additionally, the zAAP-eligible work is like any other work, in that there
can be multiple service class periods, each with its own dispatching
priority. z/OS Dispatcher will manage the work based on dispatching
priority (which means that zAAP-eligible work running on a GCP or on a zAAP
could be interrupted by higher priority work; of course, zAAP-eligible work
running on a zAAP could be interrupted only by other zAAP-eligible work at
a higher priority). z/OS re-dispatching of zAAP-eligible work is under the
"fair access" algorithms.
Actually, this is no longer new technology. zAAPs were by z/OS V1R6 in
September 2004, and information was in the field under NDA much earlier
than that. I've been working with zAAP data and information since July
2004. In fact, the October 2004 release of CPExpert included detailed
analysis related to zAAP performance issues. Many of those performance
issues were resolved with the design changes implemented with z/OS V1R7 and
other performance issues were solved with PR/SM changes for z9 109.
There has been MUCH discussion of zAAP issues in the various IBM
publications and well over a dozen presentations by IBM describing
implementation details (including a detailed diagram of the workflow of
zAAP-eligible work when it is to be executed on zAAP).
It is even to the point where ISVs are giving presentations on zAAP (for
example: my zAAP presentation at CMG 2005, and available on my web
site). From my view, my CMG 2005 presentation was interesting only because
I talked about the changes to zAAP management with z/OS V1R7 and with z9 109.
Regards,
Don
******
Don Deese, Computer Management Sciences, Inc.
Voice: (703) 922-7027 Fax: (703) 922-7305
http://www.cpexpert.org
******
At 03:16 AM 1/20/2006, you wrote:
>>Why do you say that the overhead is greater to dispatch a zAAP than a
>>non-zAAP CPU? (I'm curious.)
>
>Well for one thing, when the dispatcher is running on a normal CPU it
>is already running on the engine where the application code will be
>dispatched. There is a separate (not externally documented) signaling
>protocol to get work fired up on a zAAP. Even on its best day that is
>going to entail more path length than an ordinary dispatch.
Are you sure? I would expect the dispatcher to run on zAAPs the same
way it does on CPs.
It is my understanding (and I may be wrong here) that there are two
WUQ (Work Unit Queues) when there are zAAPs. One is for traditional
MVS WUs (MVS-WUQ hereafter), the other for zAAP WUs (Java work, zAAP-WUQ
hereafter).
With this in mind I imagine this could be who it works:
Initially a Java TCB is put on the MVS-WUQ. When dispached the JVM
will eventually decide that it is now time to switch to a zAAP,
so the TCB is marked correspondingly and execution is suspended.
The TCB is put on the zAAP-WUQ.
If any of the zAAP engines is idle at this time it will be woken up
an dispatcher code runs the zAAP-WUQ. If all zAAPs are busy, the TCB
has to wait until one of the Java-Tasks running on a zAAP gives up
control. Probably because the JVM decided it is time to go back to
a CP to continue work. So the TCB is marked correspondingly and
execution is suspended which gives control to the dispatcher on
the zAAP.
I think most of the overhead associated with using zAAPs is from
code in the JVM needed to do the switching and of course from
the context switch when going to/coming from zAAPs.
I'm open to be correct. I'm interested in understanding this
mechanism better.
Peter Hunkeler
CREDIT SUISSE
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 1/18/2006
----------------------------------------------------------------------
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
