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: [email protected] 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
