Workload Manager helps you control the allocation of system resources by defining classes of service and allocating resources to each of these classes. Each class has a set of attributes that determine what its resource entitlements are, as well as other behaviors. Every process on the system is classified into a service class, and is thus subject to enforcement of the resource entitlements and behaviors for that class. Processes are assigned to a class either manually using manual assignment, or automatically according to user-defined classification rules.
WLM supports two levels of classes: superclasses and subclasses. Superclasses are given resource entitlements based on available system resources, and subclasses are given resource entitlements relative to the entitlements of their associated superclass. Optionally, you can define subclasses to allow for more granular control of the processes in a superclass. You can also delegate the responsibility of defining subclasses by specifying an adminuser or admingroup for a superclass.
For both the superclass and subclass levels, you can define classes, resource shares and limits, and rules using SMIT, Web-based System Manager, or the command-line interface. Applications can use the WLM APIs. Configuration definitions are kept in a set of text files called the WLM property files.
A class name is up to 16 characters in length and can contain only uppercase and lowercase letters, numbers and underscores (_). For a given WLM configuration, each superclass name must be unique. Each subclass name must be unique within that superclasses, but it can match subclass names in other superclasses. To uniquely identify every subclass, the full name of a subclass is composed of the superclass name and the subclass name separated by a dot; for example: Super.Sub.
The system administrator can define up to 64 superclasses. In addition, the following five superclasses are automatically created:
However, a few pages cannot be directly tied to any processes (and thus to any class) at the time of this classification, and this memory is charged to the Unclassified superclass. Most of this memory is correctly reclassified over time, when it is either accessed by a process, or released and reallocated to a process after WLM is started. There are no processes in the Unclassified superclass. This superclass can have physical memory shares and limits applied to it. It cannot have shares or limits for the other resource types, subclasses, or assignment rules specified.
The system administrator or a superclass administrator can define up to 61 subclasses. In addition, two special subclasses, Default and Shared, are always defined.
The attributes of a WLM class are:
Tiers represent the order in which system resources are allocated to WLM classes. The administrator can define classes in up to 10 tiers, numbered 0 through 9, with 0 being the highest or most important tier. The amount of resources available to tier 0 is all available system resources. The amount of resources available to the lower (higher number) tiers, is the amount of resources that is unused by all higher tiers. Target consumption percentages for classes are based on the number of active shares in its tier, and the amount of resource available to the tier. Since tier 0 is the only tier that is guaranteed to always have resources available to it, it is recommended that processes that are essential to system operation be classified in a class in this tier. If no tier value is specified for a class, it will be put in tier 0.
A tier can be specified at both the superclass and the subclass levels. Superclass tiers are used to specify resource allocation priority between superclasses. Subclass tiers are used to specify resource allocation priority between subclasses of the same superclass. There is no relationship among sub-tiers of different superclasses.
The inheritance attribute of a class indicates whether processes in the class should be automatically reclassified when one of the classification attributes of the process changes. When a new process is created with the fork subroutine, it automatically inherits its parent's class, whether or not inheritance is enabled. One exception is when the parent process has a tag, has its inherit tag at fork set to off, and class inheritance is off for the parent's class. In this case, the child process is reclassified according to the classification rules.
When inheritance is not enabled for a class, any process in the class is automatically classified according to the classification rules after calling any service that changes a process attribute that is used in the rule. The most common of these calls is the exec subroutine, but other subroutines that can change classification include setuid, setgid, plock, setpri, and wlm_set_tag. When inheritance is enabled, the process is not subject to reclassification based on the classification rules, and will remain in its current class. Manual assignment has priority over inheritance and can be used to reclassify processes that are in a class with inheritance enabled.
The specified value for this attribute can be either yes or no. If unspecified, inheritance will not be enabled for a class.
This attribute can be specified at both superclass and subclass level. For a subclass of a given superclass:
The localshm attribute can be specified at the superclass and the subclass levels. It is used to prevent memory segments belonging to one class from migrating to the Shared superclass or subclass when accessed by processes in other classes. The possible values for the attribute are yes or no. A value of yes means that shared memory segments in this class must remain local to the class and not migrate to the appropriate Shared class. A value of no is the default when the attribute is not specified.
Memory segments are classified on page faults. When a segment is created, it is marked as belonging to the Unclassified superclass. On the first page fault on the segment, this segment is classified into the same class as the faulting process. If, later on, a process belonging to a different class than the segment page faults on this segment, WLM considers whether the segment needs to be reclassified into the appropriate Shared class (superclass or subclass). If the faulting process and the segment belong to different superclasses, one of the following occurs:
If the faulting process and the segment belong to different subclasses of the same superclass, and the segment's subclass has the localshm attribute set to yes, the segment remains in the current class (superclass and subclass). Otherwise, the segment goes to the Shared subclass of the superclass.
Of course, if the faulting process and the segment belong to the same class (same superclass and same subclass), the segment is not reclassified regardless of the values of the localshm attributes.
The adminuser and admingroup attributes are used to delegate the superclass administration to a user or group of users:
Only one value (user or group) is allowed for each attribute. Either of them, none, or both can be specified. The user or group will have authority to do the following:
The authuser and authgroup attributes are valid for all classes. They are used to specify the user or group authorized to manually assign processes to the class (superclass or subclass). When manually assigning a process (or a group of processes) to a superclass, the assignment rules for the superclass are used to determine to which subclass of the superclass each process will be assigned.
Only one value (user or group) is allowed for each attribute. Either of them, none, or both can be specified.
The resource set attribute (called rset) can be specified for any class. Its value is the name of a resource set defined by the system administrator. The rset attribute represents a subset of the CPU resource available on the system (processor set). The default is "system," which gives access to all the CPU resources available on the system. The only restriction is that if an rset is specified for a subclass, the set of CPUs in the the set must be a subset of the CPUs available to the superclass. (For detailed information, see the mkrset command description in the AIX 5L Version 5.2 Commands Reference.)