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 that is 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 that is named batch and a pool that is 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 that are bound to the pool use this scheduler. 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.