I appreciate your insight. When you state: ³ If you¹re not invoking CMS services from non-base threads²
What precisely do you mean by CMS services? Are you referring specifically to the services defined in ³CP Programming Services² OR any call to CMS? This has the potential to derail what we are trying to achieve with CMS so I want to be absolutely sure I understand what you mean. --. .- .-. -.-- Gary Dennis On 10/19/08 2:35 PM, "Gillis, Mark" <[EMAIL PROTECTED]> wrote: > I haven¹t experienced this specific problem because IBM strongly advised us to > not allocate more than 1 virtual CPU to a mutitasking CMS application. The > reason they gave was that any CMS services called from a thread running on a > non-base CPU would need to be scheduled to run on the base CPU, so that the > overheads of this would outweigh the benefits of the extra processors. If > you¹re not invoking CMS services from non-base threads then I guess that this > won¹t be an issue for you. > > Mark Gillis > Principal Software Engineer > Tel: +61 2 8898 2678 > Fax: +61 2 8898 2600 > [EMAIL PROTECTED] > > > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf > Of Gary M. Dennis > Sent: Sunday, 19 October 2008 10:24 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: VM Virtual CPUs and Threaded CMS Applications > > If you do not have experience with threaded CMS application development, I > suggest you read anything but the balance of of this email. > > I have an application that runs under CMS and consists of three distinct > layers. > 1. The top layer is some virtualized x86 OS. > 2. The middle layer performs x86 to z translation > 3. The base layer is everything else. That includes code fragment storage, > aging, retrieval, statistics collection/ push using IUCV, etc. > > Layer two has been developed in such a way that, without layer three, it > simply translates a code fragments to z architecture code, executes that code, > then discards the translated fragment. It detects the interface stub for > layer three and, if that is present, it takes advantage of the capabilities > including prior translation reuse. > > Layer 3 is multithreaded and is the cause/source of the problem. Whether layer > 3 is run with layers 1 and 2 or in standalone test mode the results are the > same. > > First the environment: > > VM 4.3 > Number of processors: 2 > Virtual CPUs (from 2 to 6 .. See note below) > > Now the application from 10,000 feet: > > Layer three consists of a parent thread that creates 4 additional threads. > Each thread is created in a dispatch class that is unique. > > Routines are not shared between threads. Upon entry into each routine, the > preamble is destroyed and restored on exit to trap any potential inadvertent > share. Critical fields shared between threads are protected by a compare and > swap spin lock. > > Part of the testing consists of pushing 1WAY IUCV messages from each connected > client every 20 milliseconds. > > The VM directory for each of 4 machines (one server and three clients) defines > the machine as an XC mode machine with: > > CPU 00 BASE > CPU 01 > > > As each thread is created it requests either BASE or ANY CPU affinity. BASE > affinity is reserved for the parent and IUCV message handler threads . ANY is > used for all other threads . Each affinity request receives a normal return > code. > > All this works beautifully for days and millions of messages UNTIL the number > of virtual CPUs defined exceed the number of real CPUs assigned to the VM > image. When this takes place, everything comes unstuck. By everything I mean > everything in CMS. Stack overflow (03FF abend), free storage management > failure, all of it. > > The multitasking application dev guide states that to the extent possible, > dispatch classes are assigned to vCPUs and further states that the max number > of vCPUs that may be utilized is equal to the number of dispatch classes. > Whether the vCPUs are defined in the user directory entry OR they are created > dynamically using the CPU Create CMS function, the results are the same. > > > My questions) > 1. Has anyone had a similar experience? > 2. Is this a known issue with 4.3? Or in more current releases? > 3. Although this seems to be telling me no to go there, I¹ve tried but cannot > find anything that says ³You¹ll shoot your eye out , kid.² if you define more > virtual CPUs than real processors. Anyone know of such a restriction? > 4. Is it possible that CMS kernel services don¹t tolerate a situation where > the number of virtual CPUs exceeds ³real² processors? > > Thanks in advance for any insight you might have on this behavior. > > --. .- .-. -.-- > > Gary Dennis > Mantissa Corporation >
