usr/src/man/man7/FSS.7

   1 '\" te
   2 .\" Copyright (c) 2001, Sun Microsystems, Inc. All Rights Reserved
   3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6 .TH FSS 7 "Oct 1, 2004"
   7 .SH NAME
   8 FSS \- Fair share scheduler
   9 .SH DESCRIPTION
  10 .sp
  11 .LP
  12 The fair share scheduler (FSS) guarantees application performance by explicitly
  13 allocating shares of CPU resources to projects. A share indicates a project's
  14 entitlement to available CPU resources. Because shares are meaningful only in
  15 comparison with other project's shares, the absolute quantity of shares is not
  16 important. Any number that is in proportion with the desired CPU entitlement
  17 can be used.
  18 .sp
  19 .LP
  20 The goals of the FSS scheduler differ from the traditional time-sharing
  21 scheduling class (TS). In addition to scheduling individual LWPs, the FSS
  22 scheduler schedules projects against each other, making it impossible for any
  23 project to acquire more CPU cycles simply by running more processes
  24 concurrently.
  25 .sp
  26 .LP
  27 A project's entitlement is individually calculated by FSS independently for
  28 each processor set if the project contains processes bound to them. If a
  29 project is running on more than one processor set, it can have different
  30 entitlements on every set. A project's entitlement is defined as a ratio
  31 between the number of shares given to a project and the sum of shares of all
  32 active projects running on the same processor set. An active project is one
  33 that has at least one running or runnable process. Entitlements are recomputed
  34 whenever any project becomes active or inactive, or whenever the number of
  35 shares is changed.
  36 .sp
  37 .LP
  38 Processor sets represent virtual machines in the FSS scheduling class and
  39 processes are scheduled independently in each processor set. That is, processes
  40 compete with each other only if they are running on the same processor set.
  41 When a processor set is destroyed, all processes that were bound to it are
  42 moved to the default processor set, which always exists. Empty processor sets
  43 (that is, sets without processors in them) have no impact on the FSS scheduler
  44 behavior.
  45 .sp
  46 .LP
  47 If a processor set contains a mix of TS/IA and FSS processes, the fairness of
  48 the FSS scheduling class can be compromised because these classes use the same
  49 range of priorities. Fairness is most significantly affected if processes
  50 running in the TS scheduling class are CPU-intensive and are bound to
  51 processors within the processor set. As a result, you should avoid having
  52 processes from TS/IA and FSS classes share the same processor set. RT and FSS
  53 processes use disjoint priority ranges and therefore can share processor sets.
  54 .sp
  55 .LP
  56 As projects execute, their CPU usage is accumulated over time. The FSS
  57 scheduler periodically decays CPU usages of every project by multiplying it
  58 with a decay factor, ensuring that more recent CPU usage has greater weight
  59 when taken into account for scheduling. The FSS scheduler continually adjusts
  60 priorities of all processes to make each project's relative CPU usage converge
  61 with its entitlement.
  62 .sp
  63 .LP
  64 While FSS is designed to fairly allocate cycles over a long-term time period,
  65 it is possible that projects will not receive their allocated shares worth of
  66 CPU cycles due to uneven demand. This makes one-shot, instantaneous analysis of
  67 FSS performance data unreliable.
  68 .sp
  69 .LP
  70 Note that share is not the same as utilization. A project may be allocated 50%
  71 of the system, although on the average, it uses just 20%. Shares serve to cap a
  72 project's CPU usage only when there is competition from other projects running
  73 on the same processor set. When there is no competition, utilization may be
  74 larger than entitlement based on shares. Allocating a small share to a busy
  75 project slows it down but does not prevent it from completing its work if the
  76 system is not saturated.
  77 .sp
  78 .LP
  79 The configuration of CPU shares is managed by the name server as a property of
  80 the \fBproject\fR(4) database. In the following example, an entry in the
  81 \fB/etc/project\fR file sets the number of shares for project \fBx-files\fR to
  82 10:
  83 .sp
  84 .in +2
  85 .nf
  86 x-files:100::::project.cpu-shares=(privileged,10,none)
  87 .fi
  88 .in -2
  89
  90 .sp
  91 .LP
  92 Projects with undefined number of shares are given one share each. This means
  93 that such projects are treated with equal importance. Projects with 0 shares
  94 only run when there are no projects with non-zero shares competing for the same
  95 processor set. The maximum number of shares that can be assigned to one project
  96 is 65535.
  97 .sp
  98 .LP
  99 You can use the \fBprctl\fR(1) command to determine the current share
 100 assignment for a given project:
 101 .sp
 102 .in +2
 103 .nf
 104 $ prctl -n project.cpu-shares -i project x-files
 105 .fi
 106 .in -2
 107
 108 .sp
 109 .LP
 110 or to change the amount of shares if you have root privileges:
 111 .sp
 112 .in +2
 113 .nf
 114 # prctl -r -n project.cpu-shares -v 5 -i project x-files
 115 .fi
 116 .in -2
 117
 118 .sp
 119 .LP
 120 See the \fBprctl\fR(1) man page for additional information on how to modify and
 121 examine resource controls associated with active processes, tasks, or projects
 122 on the system. See \fBresource_controls\fR(5) for a description of the resource
 123 controls supported in the current release of the Solaris operating system.
 124 .sp
 125 .LP
 126 By default, project \fBsystem\fR (project ID 0) includes all system daemons
 127 started by initialization scripts and has an "unlimited" amount of shares. That
 128 is, it is always scheduled first no matter how many shares are given to other
 129 projects.
 130 .sp
 131 .LP
 132 The following command sets FSS as the default scheduler for the system:
 133 .sp
 134 .in +2
 135 .nf
 136 # dispadmin -d FSS
 137 .fi
 138 .in -2
 139
 140 .sp
 141 .LP
 142 This change will take effect on the next reboot. Alternatively, you can move
 143 processes from the time-share scheduling class (as well as the special case of
 144 init) into the FSS class without changing your default scheduling class and
 145 rebooting by becoming \fBroot\fR, and then using the \fBpriocntl\fR(1) command,
 146 as shown in the following example:
 147 .sp
 148 .in +2
 149 .nf
 150 # priocntl -s -c FSS -i class TS
 151 # priocntl -s -c FSS -i pid 1
 152 .fi
 153 .in -2
 154
 155 .SH CONFIGURING SCHEDULER WITH DISPADMIN
 156 .sp
 157 .LP
 158 You can use the \fBdispadmin\fR(1M) command to examine and tune the FSS
 159 scheduler's time quantum value. Time quantum is the amount of time that a
 160 thread is allowed to run before it must relinquish the processor. The following
 161 example dumps the current time quantum for the fair share scheduler:
 162 .sp
 163 .in +2
 164 .nf
 165 $ dispadmin -g -c FSS
 166         #
 167         # Fair Share Scheduler Configuration
 168         #
 169         RES=1000
 170         #
 171         # Time Quantum
 172         #
 173         QUANTUM=110
 174 .fi
 175 .in -2
 176
 177 .sp
 178 .LP
 179 The value of the QUANTUM represents some fraction of a second with the
 180 fractional value determied by the reciprocal value of RES. With the default
 181 value of RES = 1000, the reciprocal of 1000 is .001, or milliseconds. Thus, by
 182 default, the QUANTUM value represents the time quantum in milliseconds.
 183 .sp
 184 .LP
 185 If you change the RES value using \fBdispadmin\fR with the \fB-r\fR option, you
 186 also change the QUANTUM value. For example, instead of quantum of 110 with RES
 187 of 1000, a quantum of 11 with a RES of 100 results. The fractional unit is
 188 different while the amount of time is the same.
 189 .sp
 190 .LP
 191 You can use the \fB-s\fR option to change the time quantum value. Note that
 192 such changes are not preserved across reboot. Please refer to the
 193 \fBdispadmin\fR(1M) man page for additional information.
 194 .SH ATTRIBUTES
 195 .sp
 196 .LP
 197 See \fBattributes\fR(5) for descriptions of the following attributes:
 198 .sp
 199
 200 .sp
 201 .TS
 202 box;
 203 l l
 204 l l .
 205 ATTRIBUTE TYPE  ATTRIBUTE VALUE
 206 Architecture    SUNWcsu
 207 .TE
 208
 209 .SH SEE ALSO
 210 .sp
 211 .LP
 212 \fBprctl\fR(1), \fBpriocntl\fR(1), \fBdispadmin\fR(1M), \fBpsrset\fR(1M),
 213 \fBpriocntl\fR(2), \fBproject\fR(4), \fBattributes\fR(5),
 214 \fBresource_controls\fR(5)
 215 .sp
 216 .LP
 217 \fISystem Administration Guide:  Virtualization Using the Solaris Operating
 218 System\fR