Print this page
9842 man page typos and spelling
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/man/man7/FSS.7.man.txt
+++ new/usr/src/man/man7/FSS.7.man.txt
1 1 FSS(7) Device and Network Interfaces FSS(7)
2 2
3 3
4 4
5 5 NAME
6 6 FSS - Fair share scheduler
7 7
8 8 DESCRIPTION
9 9 The fair share scheduler (FSS) guarantees application performance by
10 10 explicitly allocating shares of CPU resources to projects. A share
11 11 indicates a project's entitlement to available CPU resources. Because
12 12 shares are meaningful only in comparison with other project's shares,
13 13 the absolute quantity of shares is not important. Any number that is in
14 14 proportion with the desired CPU entitlement can be used.
15 15
16 16
17 17 The goals of the FSS scheduler differ from the traditional time-sharing
18 18 scheduling class (TS). In addition to scheduling individual LWPs, the
19 19 FSS scheduler schedules projects against each other, making it
20 20 impossible for any project to acquire more CPU cycles simply by running
21 21 more processes concurrently.
22 22
23 23
24 24 A project's entitlement is individually calculated by FSS independently
25 25 for each processor set if the project contains processes bound to them.
26 26 If a project is running on more than one processor set, it can have
27 27 different entitlements on every set. A project's entitlement is defined
28 28 as a ratio between the number of shares given to a project and the sum
29 29 of shares of all active projects running on the same processor set. An
30 30 active project is one that has at least one running or runnable
31 31 process. Entitlements are recomputed whenever any project becomes
32 32 active or inactive, or whenever the number of shares is changed.
33 33
34 34
35 35 Processor sets represent virtual machines in the FSS scheduling class
36 36 and processes are scheduled independently in each processor set. That
37 37 is, processes compete with each other only if they are running on the
38 38 same processor set. When a processor set is destroyed, all processes
39 39 that were bound to it are moved to the default processor set, which
40 40 always exists. Empty processor sets (that is, sets without processors
41 41 in them) have no impact on the FSS scheduler behavior.
42 42
43 43
44 44 If a processor set contains a mix of TS/IA and FSS processes, the
45 45 fairness of the FSS scheduling class can be compromised because these
46 46 classes use the same range of priorities. Fairness is most
47 47 significantly affected if processes running in the TS scheduling class
48 48 are CPU-intensive and are bound to processors within the processor set.
49 49 As a result, you should avoid having processes from TS/IA and FSS
50 50 classes share the same processor set. RT and FSS processes use disjoint
51 51 priority ranges and therefore can share processor sets.
52 52
53 53
54 54 As projects execute, their CPU usage is accumulated over time. The FSS
55 55 scheduler periodically decays CPU usages of every project by
56 56 multiplying it with a decay factor, ensuring that more recent CPU usage
57 57 has greater weight when taken into account for scheduling. The FSS
58 58 scheduler continually adjusts priorities of all processes to make each
59 59 project's relative CPU usage converge with its entitlement.
60 60
61 61
62 62 While FSS is designed to fairly allocate cycles over a long-term time
63 63 period, it is possible that projects will not receive their allocated
64 64 shares worth of CPU cycles due to uneven demand. This makes one-shot,
65 65 instantaneous analysis of FSS performance data unreliable.
66 66
67 67
68 68 Note that share is not the same as utilization. A project may be
69 69 allocated 50% of the system, although on the average, it uses just 20%.
70 70 Shares serve to cap a project's CPU usage only when there is
71 71 competition from other projects running on the same processor set. When
72 72 there is no competition, utilization may be larger than entitlement
73 73 based on shares. Allocating a small share to a busy project slows it
74 74 down but does not prevent it from completing its work if the system is
75 75 not saturated.
76 76
77 77
78 78 The configuration of CPU shares is managed by the name server as a
79 79 property of the project(4) database. In the following example, an entry
80 80 in the /etc/project file sets the number of shares for project x-files
81 81 to 10:
82 82
83 83 x-files:100::::project.cpu-shares=(privileged,10,none)
84 84
85 85
86 86
87 87 Projects with undefined number of shares are given one share each. This
88 88 means that such projects are treated with equal importance. Projects
89 89 with 0 shares only run when there are no projects with non-zero shares
90 90 competing for the same processor set. The maximum number of shares that
91 91 can be assigned to one project is 65535.
92 92
93 93
94 94 You can use the prctl(1) command to determine the current share
95 95 assignment for a given project:
96 96
97 97 $ prctl -n project.cpu-shares -i project x-files
98 98
99 99
100 100
101 101 or to change the amount of shares if you have root privileges:
102 102
103 103 # prctl -r -n project.cpu-shares -v 5 -i project x-files
104 104
105 105
106 106
107 107 See the prctl(1) man page for additional information on how to modify
108 108 and examine resource controls associated with active processes, tasks,
109 109 or projects on the system. See resource_controls(5) for a description
110 110 of the resource controls supported in the current release of the
111 111 Solaris operating system.
112 112
113 113
114 114 By default, project system (project ID 0) includes all system daemons
115 115 started by initialization scripts and has an "unlimited" amount of
116 116 shares. That is, it is always scheduled first no matter how many shares
117 117 are given to other projects.
118 118
119 119
120 120 The following command sets FSS as the default scheduler for the system:
121 121
122 122 # dispadmin -d FSS
123 123
124 124
125 125
126 126 This change will take effect on the next reboot. Alternatively, you can
127 127 move processes from the time-share scheduling class (as well as the
128 128 special case of init) into the FSS class without changing your default
129 129 scheduling class and rebooting by becoming root, and then using the
130 130 priocntl(1) command, as shown in the following example:
131 131
132 132 # priocntl -s -c FSS -i class TS
133 133 # priocntl -s -c FSS -i pid 1
134 134
135 135
136 136 CONFIGURING SCHEDULER WITH DISPADMIN
137 137 You can use the dispadmin(1M) command to examine and tune the FSS
138 138 scheduler's time quantum value. Time quantum is the amount of time that
139 139 a thread is allowed to run before it must relinquish the processor. The
140 140 following example dumps the current time quantum for the fair share
141 141 scheduler:
142 142
143 143 $ dispadmin -g -c FSS
144 144 #
145 145 # Fair Share Scheduler Configuration
|
↓ open down ↓ |
145 lines elided |
↑ open up ↑ |
146 146 #
147 147 RES=1000
148 148 #
149 149 # Time Quantum
150 150 #
151 151 QUANTUM=110
152 152
153 153
154 154
155 155 The value of the QUANTUM represents some fraction of a second with the
156 - fractional value determied by the reciprocal value of RES. With the
156 + fractional value determined by the reciprocal value of RES. With the
157 157 default value of RES = 1000, the reciprocal of 1000 is .001, or
158 158 milliseconds. Thus, by default, the QUANTUM value represents the time
159 159 quantum in milliseconds.
160 160
161 161
162 162 If you change the RES value using dispadmin with the -r option, you
163 163 also change the QUANTUM value. For example, instead of quantum of 110
164 164 with RES of 1000, a quantum of 11 with a RES of 100 results. The
165 165 fractional unit is different while the amount of time is the same.
166 166
167 167
168 168 You can use the -s option to change the time quantum value. Note that
169 169 such changes are not preserved across reboot. Please refer to the
170 170 dispadmin(1M) man page for additional information.
171 171
172 172
173 173 SEE ALSO
174 174 prctl(1), priocntl(1), dispadmin(1M), psrset(1M), priocntl(2),
175 175 project(4), resource_controls(5)
176 176
177 177
178 178 System Administration Guide: Virtualization Using the Solaris
179 179 Operating System
180 180
181 181
182 182
183 183 May 13, 2017 FSS(7)
|
↓ open down ↓ |
17 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX