La commande 'schedo' permet de gérer( afficher ou modifier) les paramètres systèmes du scheduler d'une partition AIX.
# schedo -a
%usDelta = 100
affinity_lim = 7
allowMCMmigrate = 0
big_tick_size = 1
ded_cpu_donate_thresh = 80
fast_locks = n/a
fixed_pri_global = 0
force_grq = 0
hotlocks_enable = 0
idle_migration_barrier = 4
krlock_confer2self = 1
krlock_conferb4alloc = 1
krlock_enable = 1
krlock_spinb4alloc = 1
krlock_spinb4confer = 1024
maxspin = 16384
n_idle_loop_vlopri = 100
pacefork = 10
proc_disk_stats = 1
sched_D = 16
sched_R = 16
search_globalrq_mload = 256
search_smtrunq_mload = 256
setnewrq_sidle_mload = 384
shed_primrunq_mload = 64
sidle_S1runq_mload = 64
sidle_S2runq_mload = 134
sidle_S3runq_mload = 134
sidle_S4runq_mload = 4294967040
slock_spinb4confer = 1024
smt_snooze_delay = 0
smtrunq_load_diff = 2
tb_balance_S0 = 0
tb_balance_S1 = 2
tb_threshold = 100
timeslice = 1
unboost_inflih = 1
v_exempt_secs = 2
v_min_process = 2
v_repage_hi = 0
v_repage_proc = 4
v_sec_wait = 1
vpm_fold_policy = 1
vpm_xvcpus = 0
Ci-dessous, un extrait de la documentation officielle IBM.
Commands Reference, Volume 5, s - u
schedo Command
Purpose
Manages processor scheduler tunable parameters.
Syntax
schedo [ -p | -r ] [-y ] { -o Tunable[=Newvalue]}
schedo [ -p | -r ] [-y ] { -d Tunable }
schedo [ -p | -r ] [-y ] -D
schedo [ -p | -r ] -a
schedo -h [ Tunable ]
schedo -L [Tunable ]
schedo -x [Tunable ] Note: Multiple flags -o, -d, -x, and -L flags are allowed
Description
Note: The schedo command can only be executed by root.
Use the schedo command to configure scheduler tuning parameters. This command sets or displays current or next boot values for all scheduler tuning
parameters. This command can also make permanent changes or defer changes until the next reboot. Whether the command sets or displays a parameter is
determined by the accompanying flag. The -o flag performs both actions. It can either display the value of a parameter or set a new value for a
parameter.
Understanding the Effect of Changing Tunable Parameters
Misuse of this command can cause performance degradation or operating-system failure. Be sure that you have studied the appropriate tuning sections
in the Performance management before using schedo to change system parameters.
Before modifying any tunable parameter, you should first carefully read about all its characteristics in the Tunable Parameters section below, and
follow any Refer To pointer, in order to fully understand its purpose.
You must then make sure that the Diagnosis and Tuning sections for this parameter truly apply to your situation and that changing the value of this
parameter could help improve the performance of your system.
If the Diagnosis and Tuning sections both contain only "N/A", you should probably never change this parameter unless specifically directed by AIX
development.
Priority-Calculation Parameters
The priority of most user processes varies with the amount of processor time the process has used recently. The processor scheduler's priority
calculations are based on two parameters that are set with schedo, sched_R and sched_D. The sched_R and sched_D values are in thirty-seconds (1/32);
that is, the formula used by the scheduler to calculate the amount to be added to a process's priority value as a penalty for recent processor use
is:
CPU penalty = (recently used CPU value of the process) * (r/32)
and the once-per-second recalculation of the recently used processor value of each process is:
new recently used CPU value = (old recently used CPU value of the process) * (d/32)
Both r (sched_R parameter) and d (sched_D parameter) have default values of 16. This maintains the processor scheduling behavior of previous
versions of the operating system. Before experimenting with these values, you should be familiar with "Tuning the processor scheduler" in the
Performance Management Guide.
Memory-Load-Control Parameters
The operating system scheduler performs memory load control by suspending processes when memory is over committed. The system does not swap out
processes; instead pages are stolen as they are needed to fulfill the current memory requirements. Typically, pages are stolen from suspended
processes. Memory is considered over committed when the following condition is met:
p * h s
where: p is the number of pages written to paging space in the last second
h is an integer specified by the v_repage_hi parameter
s is the number of page steals that have occurred in the last second
A process is suspended when memory is over committed and the following condition is met:
r * p f
where: r r is the number of repages that the process has accumulated in the last second
p is an integer specified by the v_repage_proc parameter
f is the number of page faults that the process has experienced in the last second
In addition, fixed-priority processes and kernel processes are exempt from being suspended.
The term repages refers to the number of pages belonging to the process, which were reclaimed and are soon after referenced again by the process.
The user also can specify a minimum multiprogramming level with the v_min_process parameter. Doing so ensures that a minimum number of processes
remain active throughout the process-suspension period. Active processes are those that are runnable and waiting for page I/O. Processes that are
waiting for events and processes that are suspended are not considered active, nor is the wait process considered active.
Suspended processes can be added back into the mix when the system has stayed below the over committed threshold for n seconds, where n is specified
by the v_sec_wait parameter. Processes are added back into the system based, first, on their priority and, second, on the length of their suspension
period.
Before experimenting with these values, you should be thoroughly familiar with "VMM memory load control tuning with the schedo command" in the
Performance Management Guide.
Time-Slice-Increment Parameter
The schedo command can also be used to change the amount of time the operating system allows a given process to run before the dispatcher is called
to choose another process to run (the time slice). The default value for this interval is a single clock tick (10 milliseconds). The timeslice
tuning parameter allows the user to specify the number of clock ticks by which the time slice length is to be increased.
In AIX Version 4, this parameter only applies to threads with the SCHED_RR scheduling policy. See Scheduling Policy for Threads.
fork() Retry Interval Parameter
If a fork() subroutine call fails because there is not enough paging space available to create a new process, the system retries the call after
waiting for a specified period of time. That interval is set with the pacefork tuning parameter.
Special Terminology for Symmetric Multithreading
Multiple run queues are supported. Under this scheme each processor has it's own run queue. Power 5 processors support symmetric multithreading,
where each physical processor has two execution engines, called hardware threads. Each hardware thread is essentially equivalent to a single
processor. Symmetric multithreading is enabled by default, but it can be disabled (or re-enabled) dynamically. When symmetric multithreading is
enabled, each hardware thread services a separate run queue. For example, on a 4-way system when symmetric multithreading is disabled or not
present, there are 4 run queues in addition to the global run queue. When symmetric multithreading is enabled, there are 8 run queues in addition to
the global run queue.
The hardware threads belonging to the same physical processor are referred to as sibling threads. A primary sibling thread is the first hardware
thread of the physical processor. A secondary sibling thread is the second hardware thread of the physical processor.
Virtual Processor Management
More virtual processors can be defined than are needed to handle the work in a partition. The overhead of dispatching virtual processors can be
reduced by using fewer virtual processors without a decrease in overall processor usage or a lack of virtual processors. Virtual processors are not
dynamically removed from the partition, but instead are not used and are used again only when additional work is available. Each virtual processor
uses a maximum of one physical processor. The number of virtual processes needed is determined by rounding up the sum of the physical processor
utilization and the vpm_xvcpus tunable:
number = ceiling( p_util + vpm_xvcpus)
Where number is the number of virtual processors that are needed, p_util is the physical processor utilization, and vpm_xvcpus is a tunable that
specifies the number of additional virtual processors to enable. If number is less than the number of currently enabled virtual processors, a
virtual processor will be disabled. If number is greater than the number of currently enabled virtual processors, a disabled virtual processor will
be enabled. Threads that are attached to a disabled virtual processor are still allowed to run on the disabled virtual processor.
Node Load
The node load, or simply load, is the average run queue depth across all run queues, including the global run queue multiplied by 256, and is
strongly smoothed over time. For example, a load of 256 means that if we have 16 CPUs (including symmetric multithreading CPUs), then we have had
approximately 16 runnable jobs in the system for the last few milliseconds.
Flags
-a
Displays the current, reboot (when used in conjunction with -r) or permanent (when used in conjunction with -p) value for all tunable
parameters, one per line in pairs Tunable = Value. For the permanent option, a value is only displayed for a parameter if its reboot and
current values are equal. Otherwise NONE displays as the value.
-d Tunable
ResetsTunable to its default value. If a tunable needs to be changed (that is, it is currently not set to its default value, and -r is not used
in combination, it won't be changed but a warning is displayed.
-D
Resets all tunables to their default value. If tunables needing to be changed are of type Bosboot or Reboot, or are of type Incremental and
have been changed from their default value, and -r is not used in combination, they will not be changed but a warning displays.
-h [Tunable]
Displays help about the Tunable parameter if one is specified. Otherwise, displays the schedo command usage statement.
-L [ Tunable ]
Lists the characteristics of one or all tunables, one per line, using the following format:
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
v_repage_hi 0 0 0 0 2047M D
--------------------------------------------------------------------------------
v_repage_proc 4 4 4 0 2047M D
--------------------------------------------------------------------------------
v_sec_wait 1 1 1 0 2047M seconds D
--------------------------------------------------------------------------------
...
where:
CUR = current value
DEF = default value
BOOT = reboot value
MIN = minimal value
MAX = maximum value
UNIT = tunable unit of measure
TYPE = parameter type: D (for Dynamic), S (for Static), R (for Reboot),
B (for Bosboot), M (for Mount), I (for Incremental), C (for Connect), and d (for Deprecated)
DEPENDENCIES = list of dependent tunable parameters, one per line
-o Tunable [=Newvalue]
Displays the value or sets Tunable to Newvalue. If a tunable needs to be changed (the specified value is different than current value), and is
of type Bosboot or Reboot, or if it is of type Incremental and its current value is bigger than the specified value, and -r is not used in
combination, it will not be changed but a warning displays.
When -r is used in combination without a new value, the nextboot value for tunable is displayed. When -p is used in combination without a new
value, a value displays only if the current and next boot values for tunable are the same. Otherwise NONE displays as the value.
-p
Makes changes apply to both current and reboot values, when used in combination with -o, -d or -D, that is, turns on the updating of the
/etc/tunables/nextboot file in addition to the updating of the current value. These combinations cannot be used on Reboot and Bosboot type
parameters because their current value can't be changed.
When used with -a or -o without specifying a new value, values are displayed only if the current and next boot values for a parameter are the
same. Otherwise NONE displays as the value.
-r
Makes changes apply to reboot values when used in combination with -o, -d or -D, that is, turns on the updating of the /etc/tunables/nextboot
file. If any parameter of type Bosboot is changed, the user will be prompted to run bosboot.
When used with -a or -o without specifying a new value, next boot values for tunables display instead of current values.
-x [Tunable]
Lists characteristics of one or all tunables, one per line, using the following (spreadsheet) format:
tunable,current,default,reboot,min,max,unit,type,{dtunable }
where:
current = current value
default = default value
reboot = reboot value
min = minimal value
max = maximum value
unit = tunable unit of measure
type = parameter type: D (for Dynamic), S (for Static), R (for Reboot),
B (for Bosboot),M (for Mount), I (for Incremental),
C (for Connect), and d (for Deprecated)
dtunable = space separated list of dependent tunable parameters
-y
Suppresses the confirmation prompt before executing the bosboot command.
Any change (with -o, -d or -D) to a parameter of type Mount results in a message displaying to warn the user that the change is only effective for
future mountings.
Any change (with -o, -d or -D flags) to a parameter of type Connect will result in inetd being restarted, and in a message being displayed to warn
the user that the change is only effective for future socket connections.
Any attempt to change (with -o, -d or -D) a parameter of type Bosboot or Reboot without -r, results in an error message.
Any attempt to change (with-o, -d or -D but without -r) the current value of a parameter of type Incremental with a new value smaller than the
current value, results in an error message.
Tunable Parameters Type
All the tunable parameters manipulated by the tuning commands (no, nfso, vmo, ioo, raso, and schedo) have been classified into these categories:
Dynamic
If the parameter can be changed at any time
Static
If the parameter can never be changed
Reboot
If the parameter can only be changed during reboot
Bosboot
If the parameter can only be changed by running bosboot and rebooting the machine
Mount
If changes to the parameter are only effective for future file systems or directory mounts
Incremental
If the parameter can only be incremented, except at boot time
Connect
If changes to the parameter are only effective for future socket connections
Deprecated
If changing this parameter is no longer supported by the current release of AIX.
For parameters of type Bosboot, whenever a change is performed, the tuning commands automatically prompt the user to ask if they want to execute the
bosboot command. For parameters of type Connect, the tuning commands automatically restart the inetd daemon.
Note that the current set of parameters managed by the schedo command only includes Dynamic, and Reboot types.
Compatibility Mode
When running in pre 5.2 compatibility mode (controlled by the pre520tune attribute of sys0, see AIX 5.2 compatibility mode in the Performance
management), reboot values for parameters, except those of type Bosboot, are not really meaningful because in this mode they are not applied at boot
time.
In pre 5.2 compatibility mode, setting reboot values to tuning parameters continues to be achieved by imbedding calls to tuning commands in scripts
called during the boot sequence. Parameters of type Reboot can therefore be set without the -r flag, so that existing scripts continue to work.
This mode is automatically turned ON when a machine is MIGRATED to AIX 5.2. For complete installations, it is turned OFF and the reboot values for
parameters are set by applying the content of the /etc/tunables/nextboot file during the reboot sequence. Only in that mode are the -r and -p flags
fully functional. See Kernel Tuning in the AIX 5L Version 5.3 Performance Tools Guide and Reference for more information.
Tunable Parameters
affinity_lim
Purpose:
Sets the number of intervening dispatches after which the SCHED_FIFO2 policy no longer favors a thread.
Values:
* Default: 7
* Range: 0 to 100
* Type: Dynamic
Diagnosis:
N/A
Tuning:
Once a thread is running with SCHED_FIFO2 policy, tuning of this variable may or may not have an effect on the performance of the thread
and workload. Ideal values should be determined by trial and error.
Refer To:
Scheduling policy for threads
allowMCMmigrate
Purpose:
Enables (1) or disables (0) the weakening of barriers for migration threads between MCMs under light load conditions.
Values:
* Default: 0 (disabled)
* Range: 0 to 1
* Type: Boolean
Diagnosis:
N/A
Tuning:
N/A
big_tick_size
Purpose:
Sets physical tick interval & synchronizes ticks across cpus.
Values:
* Default: 1
* Range: 1 to 100
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This value multiplied by 10 ms is the tick interval, and should evenly divide into 100. Use of this parameter will make system
statistics less accurate.
fixed_pri_global
Purpose:
Keep fixed priority threads on global run queue.
Values:
* Default: 0
* Range: 0 to 1
* Type: Dynamic
Diagnosis:
N/A
Tuning:
If 1, then fixed priority threads are placed on the global run queue.
Refer To:
Scheduler run queue
force_grq
Purpose:
Keep non-MPI threads on the global run queue.
Values:
* Default: 0
* Range: 0 or 1
* Type: Dynamic
Diagnosis:
N/A
Tuning:
If set to 1, only MPI and bound threads will use local run queues, which may hurt performance.
hotlocks_enable
Purpose:
Enables (1) or disables (0) the hardware priority boosting of hot locks.
Values:
* Default: 0 (disabled)
* Range: 0...1
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
idle_migration_barrier
Purpose:
Used to determine when threads can be migrated to other processors.
Values:
* Default: 4
* Range: 0 to 100
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This value is divided by 16 and then multiplied by the load average. The resulting value is used to determine if jobs should be migrated
to other nodes (essentially does load balancing).
krlock_confer2self
Purpose:
Enables (1) or disables (0) conferring to self after trying to acquire krlock krlock_spinb4confer times. This parameter only applies to
the 64-bit kernel.
Values:
* Default: 0 (disabled)
* Range: 0...1
* Type: Dynamic (Reboot when 32-bit kernel is running.)
Diagnosis:
N/A
Tuning:
N/A
krlock_conferb4alloc
Purpose:
Enables (1) or disables (0) conferring after spinning slock_spinb4confer before trying to acquire or allocating krlock. This parameter
only applies to the 64-bit kernel.
Values:
* Default: 1
* Range: 0...1
* Type: Dynamic (Reboot when 32-bit kernel is running.)
Diagnosis:
N/A
Tuning:
N/A
krlock_enable
Purpose:
Enables (1) or disables (0) krlocks. This parameter only applies to the 64-bit kernel.
Values:
* Default: 1 (enabled)
* Range: 0...1
* Type: Dynamic (Reboot when 32-bit kernel is running.)
Diagnosis:
N/A
Tuning:
N/A
krlock_spinb4alloc
Purpose:
Number of additional acquisition attempts after spinning slock_spinb4confer, and conferring (if krlock_conferb4alloc is on), before
allocating krlock. This parameter only applies to the 64-bit kernel.
Values:
* Default: 1
* Range: 1...MAXINT
* Type: Dynamic (Reboot when 32-bit kernel is running.)
Diagnosis:
N/A
Tuning:
N/A
krlock_spinb4confer
Purpose:
Number of krlock acquisition attempts before conferring to the krlock holder (or self). This parameter only applies to the 64-bit
kernel.
Values:
* Default: 1024
* Range: 0...MAXINT
* Type: Dynamic (Reboot when 32-bit kernel is running.)
Diagnosis:
N/A
Tuning:
N/A
maxspin
Purpose:
Sets the number of times to spin on a kernel lock before going to sleep.
Values:
* Default: 1 on uniprocessor systems, -1 on MP systems, which means to spin up to 232 times
* Range: -1 to 232
* Type: Dynamic
Diagnosis:
N/A
Tuning:
Increasing the value or setting it to -1 on MP systems may reduce idle time; however, it may also waste processor time in some
situations. Increasing it on uniprocessor systems is not recommended.
Refer To:
Use of the schedo command to modify the MAXSPIN parameter
n_idle_loop_vlopri
Purpose:
Number of times to run the low hardware priority loop each time in idle loop if no new work is found.
Values:
* Default: 100
* Range: 0...1000000
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
pacefork
Purpose:
The number of clock ticks to wait before retrying a failed fork call that has failed for lack of paging space.
Values:
* Default: 10
* Range: a positive number of clock ticks bigger than 10
* Type: Dynamic
Diagnosis:
System is running out of paging space and process cannot be forked.
Tuning:
The system will retry a failed fork five times. For example, if a fork() subroutine call fails because there is not enough paging space
available to create a new process, the system retries the call after waiting the specified number of clock ticks.
Refer To:
The fork() retry interval parameter
sched_D
Purpose:
Sets the short term processor usage delay rate.
Values:
* Default: 16
* Range: 0 to 32
* Type: Dynamic
Diagnosis:
N/A
Tuning:
The default is to decay short-term processor usage by 1/2 (16/32) every second. Decreasing this value enables foreground processes to
avoid competition with background processes for a longer time.
Refer To:
Thread-Priority-Value calculation
sched_R
Purpose:
Sets the weighting factor for short-term processor usage in priority calculations.
Values:
* Default: 16
* Range: 0 to 32
* Type: Dynamic
Diagnosis:
Run: ps al. If you find that the PRI column has priority values for foreground processes (those with NI values of 20) that are higher
than the PRI values of some background processes (NI values > 20), you can reduce the r value.
Tuning:
The default is to include 1/2 (16/32) of the short term processor usage in the priority calculation. Decreasing this value makes it
easier for foreground processes to compete.
Refer To:
Thread-Priority-Value calculation
search_globalrq_mload
Purpose:
Minimum load above which secondary sibling threads will look for work in the global run queue in the dispatcher.
Values:
* Default: 256
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
search_smtrunq_mload
Purpose:
Minimum load above which the dispatcher will also search the run queues belonging to its sibling hardware threads. This is meant for
load balancing on a physical processor and is not the same as idle load balancing as this check is made in the dispatcher when choosing
the next job to be dispatched. This works in conjunction with the smtrunq_load_diff tunable.
Values:
* Default: 256
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
setnewrq_sidle_mload
Purpose:
Minimum system load above which idle secondary sibling threads will be considered for new work even when primary is not idle.
Values:
* Default: 384
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
shed_primrunq_mload
Purpose:
The maximum load below which the secondary sibling threads will try to shed work onto the primary sibling thread's run queue.
Values:
* Default: 64
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
sidle_s1runq_mload
Purpose:
The minimum load above which idle load balancing for secondary sibling threads will search for work in the primary sibling thread's run
queue.
Values:
* Default: 64
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
sidle_S2runq_mload
Purpose:
Minimum load above which secondary sibling threads will look for work among other run queues owned by CPUs within their S2 affinity
domain during idle load balancing.
Values:
* Default: 134
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
It is recommended that this tunable never be set to a value that is less than the value of sidle_S1runq_mload.
sidle_S3runq_mload
Purpose:
Minimum load above which secondary sibling threads will look for work among other run queues owned by CPUs within their S3 affinity
domain during idle load balancing.
Values:
* Default: 134
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
It is recommended that this tunable never be set to a value that is less than the value of sidle_S2runq_mload.
sidle_S4runq_mload
Purpose:
Minimum load above which secondary sibling threads will look for work on any local run queues.
Values:
* Default: 4294967040
* Range: 0...4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
It is recommended that this tunable never be set to a value that is less than the value of sidle_S3runq_mload.
slock_spinb4confer
Purpose:
Number of attempts for a simple lock before conferring.
Values:
* Default: 1024
* Range: 0...MAXINT
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
smt_snooze_delay
Purpose:
Amount of time in microseconds in idle loop without useful work before snoozing (calling h_cede). A value of -1 indicates to disable
snoozing, a value of 0 indicates to snooze immediately.
Values:
* Default: 0
* Range: -1..100000000 (100 secs)
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
smtrunq_load_diff
Purpose:
Minimum load difference between dibling run queue loads for a task to be stolen from the sibling's run queue. This is enabled only when
the load is greater than the value for the search_smtrunq_mload tunable.
Values:
* Default: 2
* Range: 1..4294967040
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
tb_balance_s0
Purpose:
Controls SMT-cores busy balancing. This balancing attempts to keep compute-bound threads spread across physical resources.
Values:
* Default: 0 (balancing disabled)
* Range: 0, 1, or 2. A value of 1 indicates balancing enabled within MCMs (S2 groups).
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
tb_balance_s1
Purpose:
Controls chipset busy balancing. This balancing attempts to keep compute-bound threads spread across physical resources.
Values:
* Default: 1 (balancing enabled system-wide)
* Range: 0, 1, or 2. A value of 0 indicates balancing disabled. A value of 1 indicates balancing enabled within MCMs (S2 groups).
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
tb_threshold
Purpose:
Number of ticks to consider a thread busy for optimization purposes for thread_busy load balancing. This balancing attempts to keep
compute-bound threads spread across physical resources.
Values:
* Default: 100 (1 second)
* Range: 10 to 1000 (0.1 to 10 seconds)
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
timeslice
Purpose:
The number of clock ticks a thread can run before it is put back on the run queue.
Values:
* Default: 1
* Range: a positive integer value
* Type: Dynamic
Diagnosis:
N/A
Tuning:
Increasing this value can reduce overhead of dispatching threads. The value refers to the total number of clock ticks in a timeslice and
only affects fixed-priority processes.
Refer To:
Modification of the scheduler time slice with the schedo command
unboost_inflih
Purpose:
Enables (1) or disables (0) the unboost of the hot lock priority in the flih. When disabled, the unboost occurs in the dispatcher.
Values:
* Default: 1 (enabled)
* Range: 0...1
* Type: Dynamic
Diagnosis:
N/A
Tuning:
N/A
%usDelta
Purpose:
Used to adjust system clock with each clock tick in the correction range -1 to +1 seconds.
Values:
* Default: 100
* Range: 0 to 100
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This is used to adjust clock drifts.
v_exempt_secs
Purpose:
Sets the number of seconds that a recently resumed process that was previously suspended is exempt from suspension.
Values:
* Default: 2
* Range: 0 or a positive number
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This parameter is only examined if thrashing is occurring.
Refer To:
VMM memory load control facility and VMM memory load control tuning with the schedo command.
v_min_process
Purpose:
Sets the minimum number of processes that are exempt from suspension.
Values:
* Default: 2
* Range: 0 or a positive number
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This number is in addition to kernel processes, processes with fixed priority less than 60, processes with pinned memory, or processes
awaiting events. This parameter is only examined if there are threads on the suspended queue.
Refer To:
VMM memory load control facility and VMM memory load control tuning with the schedo command.
v_repage_hi
Purpose:
Sets the system wide criteria used to determine when process suspension begins and ends (system is thrashing).
Values:
* Default: 6 unless system RAM is 128 MB or more (in this case it is 0)
* Range: 0 or a positive number
* Type: Dynamic
Diagnosis:
If v_repage_hi * page_outs/sec is > page_steals, then processes may get suspended.
Tuning:
If system is paging and causing scheduler to think it is thrashing but thrashing is not actually occurring, then it may be useful to
desensitize the algorithm by decreasing the -h value or setting it to 0.
Refer To:
VMM memory load control facility and VMM memory load control tuning with the schedo command.
v_repage_proc
Purpose:
Sets the per-process criterion used to determine which processes to suspend.
Values:
* Default: 4
* Range: 0 or a positive number
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This requires a higher level of repaging by a given process before it is a candidate for suspension by memory load control. This
parameter is examined only if thrashing is occurring.
Refer To:
VMM memory load control facility and VMM memory load control tuning with the schedo command.
v_sec_wait
Purpose:
Sets the number of seconds to wait after thrashing ends before making suspended processes runnable.
Values:
* Default: 1
* Range: 0 or a positive number
* Type: Dynamic
Diagnosis:
N/A
Tuning:
This parameter is examined only if thrashing is occurring.
Refer To:
VMM memory load control facility and VMM memory load control tuning with the schedo command.
vpm_xvcpus
Purpose:
Specifies the number of virtual processors to enable in addition to the number of virtual processors that are needed to consume the
physical processor utilization.
Values:
* Default: 0 (on)
* Range: -1 to INT_MAX
* Type: Dynamic
Diagnosis:
N/A
Tuning:
A value of -1 disables this functionality.
Examples
1 To list the current and reboot value, range, unit, type and dependencies of all tunables parameters managed by the schedo command, enter:
schedo -L
2 To list (spreadsheet format) the current and reboot value, range, unit, type and dependencies of all tunables parameters managed by the schedo
command, enter:
schedo -x
3 To reset v_sec_wait to default, enter:
schedo -d v_sec_wait
4 To display help on sched_R, enter:
schedo -h sched_R
5 To set v_min_process to 4 after the next reboot, enter:
schedo -r -o v_min_process=4
6 To permanently reset all schedo tunable parameters to default, enter:
schedo -p -D
7 To list the reboot value for all schedo parameters, enter:
schedo -r -a
Related Information
The vmo command, ioo command, no command, nfso command, raso command, tunchange command, tunsave command, tunrestore command, tuncheck command, and
tundefault command.
Kernel Tuning in AIX 5L Version 5.3 Performance Tools Guide and Reference
AIX 5.2 compatibility mode in Performance management.
