OpenVMS Alpha Galaxy Guide
←Previous Next→ Contents Tables Close Download Help
  9.7  CPU Reassignment

  OpenVMS supports several methods of managing CPU re-
  sources.  The console establishes the default owner instance
  for each CPU using the console environment variables.  This
  allows the CPU resources to be statically assigned, providing
  a precise initial configuration.  In the event of a cold boot (that
  is, power cycle or initialization), this default configuration is
  restored from console nonvolatile RAM.

  Once a configuration has been booted, OpenVMS provides
  more elegant means of assigning resources for users with
  CMKRNL (Change Mode to Kernel) privilege.  The following
  sections describe these methods.

  9.7.1  DCL Reassignment
  Users with CMKRNL privilege can perform CPU reassign-
  ment operations using the following DCL command:

  $  STOP/CPU/MIGRATE=instance-or-id    cpu-id

  The user must provide the target instance name (SCSNAME)
  or numeric ID (0, 1, and so on), and the numeric ID of the

  CPU being reassigned.  The following examples show a few
  forms of this command.

  $  STOP/CPU/MIGRATE=0   4       !Reassign  CPU  4  to  instance  0
  $  STOP/CPU/MIGRATE=1   3,4,5   !Reassign  CPUs  3,4,5  to  instance  1
  $  STOP/CPU  7/MIGRATE=BIGBNG   !ReassignCPU  7  to  instance  BIGBNG
  $  STOP/CPU/ALL/MIGRATE=0      !Reassign  all  secondary  CPUs  to  instance  0

  These commands can be inserted in to command procedures.

  For example, you might want to move extra CPU resources
  to an instance in a startup procedure of an application with
  known processing requirements.  Similarly, you may want to
  reassign CPUs away from an instance that is about to per-
  form lengthy, I/O intensive operations (such as backups) so
  that the CPUs are available to other instances.  When the
  job completes, you may reassign them back.  Or you may
  reassign CPUs away from an instance that is shutting down.

  Note that you can only reassign resources away from an
  instance.  This is the push model defined by the Galaxy

  Software Architecture.  This model prevents resources from
  being ``stolen'' by other instances that may not be aware of
  their current usage.  To effectively manage the entire Galaxy
  system using DCL, you must either log in to each of the in-
  volved instances or use the SYSMAN utility to execute the
  commands on the owner instance.

  9.7.2  GCU Drag-and-Drop Reassignment
  The GCU provides an interactive visual interface for man-
  aging Galaxy resources.  Using the GCU, you can reassign

  CPUs by simply dragging and dropping them among in-
  stances.  Additionally, the GCU allows you to draw charts of
  various configurations (known as configuration models), and
  save them as files.  At any time, you can load and engage a
  configuration model and the system will reassign resources
  as needed to achieve the desired model.

  9.7.3  Intermodal Reassignment
  Because of the resource push model defined by the Galaxy
  Software Architecture, resources must be given away by
  the Galaxy instance that currently owns them.  For a util-
  ity or user to effectively manage resource assignment in a
  multiple-instance Galaxy configuration, you must establish
  some means of executing commands on each instance.

  One such means is to open a window or terminal session
  on each of the Galaxy instances and perform your resource
  management operations in each of these windows.

  Another method is use the SYSMAN utility and its under-
  lying SMI-Server to establish a command environment on
  the owner instance.  Using this method, a fairly simple com-
  mand procedure can be written to perform specific resource
  management operations.  This method has some limitations,
  however.  Firts, it requires that the involved Galaxy instances
  must be in a cluster.  Also, a command procedure cannot ef-
  fectively pass variable parameters to SYSMAN environment
  scripts, and you cannot specify a remote system password
  within a SYSMAN script.  So it is cumbersome to generate
  a general-purpose command procedure interface that uses
  SYSMAN.

  The GCU does, in fact, use SYSMAN wherever possible to
  accomplish its management actions.  When a system is not
  configured to support SYSMAN, the GCU will attempt to use
  DECnet task-to-task comminations among proxy accounts
  as its management transport.  If that approach also fails (that
  is, if the system is not running DECnet or if the necessary
  proxy accounts are not set up), the GCU will not be able to
  manage Galaxy instances other than the one on which the
  GCU is currently running.  You could certainly run multi-
  ple copies of the GCU if you choose, one per Galaxy instance.
  However, you can assume that OpenVMS Galaxy systems
  are likely to be clustered or to use DECnet.

  The GCUs management actions are based in the SYS$MANAGER:GCU$ACTIONS.COM
  command procedure.  You can modify this file to customize
  actions for your own environment.  For example, in a TCP/IP
  environment, you may choose to use REXEC or similar
  utility for your management transport, or you may want
  to include some form of notification or logging whenever a
  management action is executed.

  The GCU$ACTIONS.COM file is somewhat unusual in
  the way it operates.  When using SYSMAN, the procedure
  builds small SYSMAN command scripts in temporary files
  to deal with variable parameters that SYSMAN Cannot
  handle.  When SYSMAN is not available, the procedure at-
  tempts to open a DECnet task-to-task connection to a proxy
  account on the owner instance.  If successful, it uses this
  connection to shuffle command parameters to the copy of

  GCU$ACTIONS.COM that resides on the owner instance.
  The end result is execution of the command locally by the
  owner instance.

  9.7.4  Software Reassignment Using Galaxy Services
  Perhaps the best method for managing resource assignment
  is to use the Galaxy APIs to write your own resource man-
  agement routines.  This allows you to base your decisions for
  resource management on your own criteria and application
  environment.  The same push-model restriction described in

  Section 9.7.3still exists, however, so your routines will need to
  be Galaxy aware, possibly using shared memory to coordinate
  their operations.

  For information about CPU reassignment APIs, see

  Chapter 16.

  9.7.5  Reassignment Faults

  CPU reassignment can fail or be blocked, for several rea-
  sons.  Because the GCU buries its management actions in
  SYSMAN or DCL scripts, it may not always identify and re-
  port the reasons for a reassignment fault.  The GCU does
  perform certain checks prior to allowing reassignment ac-
  tions in order, for example, to prevent attempts to reassign
  the primary CPU. Other reasons exist for reassignment
  faults that can only be detected by the operating system or
  console firmware.  For example, if the operating system de-
  tects a fault attempting to reassign a CPU that currently has
  process affinity or Fast Path duties, a DCL message will be
  displayed on both the console and the users terminal.

  The Galaxy APIs for reassignment are capable of reporting
  most faults to the caller.  However, even using the reassign-
  ment services, the console may reject a reassignment because
  of hardware platform dependencies not readily visible to the
  operating system.
←Previous Next→ Contents Tables Close Download Help