The configuration file contains a description of the pools to be created on the system. The file describes the entities and resource types that can be manipulated.
|
Type |
Description |
|---|---|
|
pset |
A processor set resource |
|
pool |
Named collection of resource associations |
|
system |
The machine-level entity |
See poolcfg(1M) for more information on elements that be manipulated.
You can create a structured /etc/pooladm.conf file in two ways.
You can use poolcfg to discover the resources on the current system and place the results in a configuration file.
This method simplifies file construction. All active resources and components on the system that are capable of being manipulated by the pools facility are recorded. The resources include existing processor set configurations. You can then modify the configuration to rename the processor sets or to create additional pools if necessary.
You can use poolcfg to create a new pools configuration.
Use this method when you develop configurations for other machines or when you create configurations that you want to apply to the current machine at a later time.
Use poolcfg or libpool to modify the /etc/pooladm.conf file. Do not directly edit this file.
Use the discover subcommand argument to the -c option of /usr/sbin/poolcfg to create the pools configuration file. The resulting file, /etc/pooladm.conf, contains any existing processor sets.
You can also supply a file name to use instead of the default /etc/pooladm.conf. If the file name is supplied, then the poolcfg commands are applied to the contents of the named file.
For example, to place a discovered configuration in /tmp/foo, do the following:
Use the create subcommand argument to the -c option of /usr/sbin/poolcfg to create a simple configuration file for a system named tester. Note that you must quote subcommand arguments that contain white space.
Become superuser.
Type the following:
# poolcfg -c 'create system tester' |
View the contents of the configuration file in readable form.
# poolcfg -c info
system tester
int system.version 1
boolean system.bind-default true
string system.comment
|
To enhance your simple configuration, create a processor set named batch and a pool named batch. Then join them with an association. Note that you must quote subcommand arguments that contain white space.
Become superuser.
Create processor set batch.
# poolcfg -c 'create pset batch (uint pset.min = 2; uint pset.max = 10)' |
Create pool batch.
# poolcfg -c 'create pool batch' |
Join with an association.
# poolcfg -c 'associate pool batch (pset batch)' |
Display the edited configuration.
# poolcfg -c info
system tester
int system.version 1
boolean system.bind-default true
string system.comment
pool batch
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
pset batch
pset batch
int pset.sys_id -2
string pset.units population
boolean pset.default true
uint pset.max 10
uint pset.min 2
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
|
You can associate a pool with a scheduling class so that all processes bound to the pool use this scheduler. To do this, set the pool.scheduler property to the name of the scheduler class. This example shows how to associate the pool batch with the FSS.
Become superuser.
Modify pool batch to be associated with the FSS.
# poolcfg -c 'modify pool batch (string pool.scheduler="FSS")' |
Display the edited configuration.
# poolcfg -c info
system tester
int system.version 1
boolean system.bind-default true
string system.comment
pool batch
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler FSS
pset batch
pset batch
int pset.sys_id -2
string pset.units population
boolean pset.default true
uint pset.max 10
uint pset.min 2
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
|
poolcfg -f can take input from a text file that contains poolcfg subcommand arguments to the -c option. This technique is appropriate when you want a set of operations to be performed atomically. When processing multiple commands, the configuration is only updated if all of the commands succeed. For large or complex configurations, this technique can be more useful than per-subcommand invocations.