In WLM, processes can be classified in either of two ways:
The automatic assignment of processes to classes uses a set of class-assignment rules specified by a WLM administrator. There are two levels of assignment rules:
The assignment rules at both levels are based on the values of a set of process attributes. These attributes are as follows:
The tag is a process attribute, defined as a character string, that an application can set by program, using the WLM API.
The classification is done whenever an attribute changes by comparing the value of these process attributes against lists of possible values given in the class assignment rules file (called rules). The comparison determines which rule is a match for the current value of the process attributes.
A class assignment rule is a text string that includes the following fields, separated by one or more spaces:
| Name | Must contain the name of a class which is defined in the class file corresponding to the level of the rules file (superclass or subclass). Class names can contain only uppercase and lowercase letters, numbers, and underscores and can be up to 16 characters in length. No assignment rule can be specified for the system defined classes Unclassified, Unmanaged and Shared. |
| Reserved | Reserved for future extension. Its value must be a hyphen (-), and it must be present. |
| User | May contain either a hyphen (-) or at least one valid user name (as defined in the /etc/passwd file). The list is composed of one or more names, separated by a comma (,). An exclamation mark (!) can be used before a name to exclude a given user from the class. Patterns can be specified to match a set of user names, using full Korn shell pattern-matching syntax. If there are no valid user names, the rule is ignored. |
| Group | May contain either a hyphen (-) or at least one valid group name (as defined in the /etc/group file). The list is composed of one or more names, separated by a comma (,). An exclamation mark (!) can be used before a name to exclude a given group from the class. Patterns can be specified to match a set of user names using full Korn shell pattern matching syntax. If there are no valid group names, the rule is ignored. |
| Application | May contain either a hyphen (-) or a list of application path names.
This is the path name of the applications (programs) executed by processes
included in the class. The application names will be either full path names
or Korn shell patterns that match path names. The list is composed of one
or more path names, separated by a comma (,). An exclamation mark (!) can
be used before a name to exclude a given application.
At least one application in the list must be found at load time or the rule is ignored. Rules that are initially ignored for this reason might become effective later on if a file system is mounted that contains one or more applications in the list. |
| Type | May contain either a hyphen (-) or a list of process attributes. The
possible values for these attributes are as follows:
|
| Tag | May contain either a hyphen (-) or a list of application tags. An application tag is a string of up to 30 alphanumeric characters. The list is composed of one or more application tag values separated by commas. |
The User, Group, Application, and Tag attributes can be an attribute value grouping.
When a process is created (fork), it remains in the same class as its parent. Reclassification happens when the new process issues a system call which can modify one of the attributes of the process used for classification; for example, exec, setuid (and related calls), setgid (and related calls), setpri and plock.
To classify the process, WLM examines the top-level rules file for the active configuration to determine which superclass the process belongs. For each rule in the file, WLM checks the current values for the process attributes against the values and lists of values specified in the rule. Rules are checked in the order that they appear in the file. When a match is found, the process is assigned to the superclass named in the first field of the rule. Then the rules file for the superclass is examined in the same way to determine to which subclass the process should be assigned.
For a process to match one of the rules, each of its attributes must match the corresponding field in the rule. The following is a list of the criteria used to determine whether the value of an attribute matches the values in the field of the rules file:
At both superclass and subclass levels, WLM goes through the rules in the order in which they appear in the rules file, and classifies the process in the class corresponding to the first rule for which the process is a match. The order of the rules in the rules file is therefore extremely important. Use caution when you create or modify the rules file.
A process or a group of processes can be manually assigned to a superclass and/or subclass by using Web-based System Manager, SMIT, or the wlmassign command. An application can assign processes through the wlm_assign API function.
To manually assign processes to a class or to cancel an existing manual assignment, a user must have the appropriate level of privilege. (See Security Considerations for further details.) A manual assignment can be made or canceled separately at the superclass level, the subclass level, or both. This assignment is specified by flags for the programming interface and a set of options for the command line interface used by the WLM administration tools. So, a process can be manually assigned to a superclass only, a subclass only, or to a superclass and a subclass of that superclass. In the latter case, the dual assignment can be done simultaneously (with a single command or API call) or at different times, by different users.
Assignment is very flexible, but can be confusing. Following are two examples of the possible cases.
A system administrator manually assigns Process1 from superclassA to superclassB (superclass-level-only assignment). The automatic assignment rules for the subclasses of superclassB are used by WLM to determine to which subclass the process is ultimately assigned. Process1 is assigned to superclassB.subclassA and is flagged as having a "superclass only" assignment.
A user with the appropriate privileges assigns Process2 from its current class superclassA.subclassA to a new subclass of the same superclass, superclassA.subclassB. Process2 is assigned to its new subclass and flagged as having a "subclass only" assignment.
A WLM administrator of the subclasses of superclassB manually reassigns Process1 to subclassC, which is another subclass of superclassB. Process1 is reclassified into superclassB.subclassC and is now flagged as having both superclass and subclass level assignment.
The reassignment and cancelation of a manual assignment at the subclass level is less complex and affects only the subclass level assignment.
Suppose that the system administrator wants Process2 to be in a superclass with more resources and decides to manually assign Process2 to superclassC. In Example 1, Process2 was manually assigned to subclassB of superclassA, with a "subclass only" assignment. Because Process2 is assigned to a different superclass, the previous manual assignment becomes meaningless and is canceled. Process2 now has a "superclass only" manual assignment to superclassC, and in the absence of inheritance, is assigned to a subclass of superclassC using the automatic assignment rules.
Now, the system administrator decides to terminate the manual assignment from Process1 to superclassB. The "superclass level" manual assignment of Process1 is canceled, and in the absence of inheritance, Process1 is assigned a superclass using the top level automatic assignment rules.
If the rules have not changed, Process1 is assigned to superclassA, and its subclass level manual assignment to superclassB.subclassC becomes meaningless and is canceled.
If for some reason the top level rules assign Process1 to superclassB, then the subclass level assignment to superclassB.subclassC is still valid and remains in effect. Process1 now has a "subclass only" manual assignment.
When WLM is updated (with the wlmcntrl -u command), the updated configuration can load a new set of classification rules. When this happens, processes are often reclassified using the new rules. WLM does not reclassify processes that have been manually assigned or that are in a class with inheritance enabled, unless their class does not exist in the new configuration.
To assign a process to a class or to cancel a prior manual assignment, the user must have authority both on the process and on the target class. These constraints translate into the following rules:
To modify or terminate a manual assignment, users must have at least the same level of privilege as the person who issued the last manual assignment.