9842 man page typos and spelling

          --- old/usr/src/man/man7/FSS.7
          +++ new/usr/src/man/man7/FSS.7

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

 168  168          #
 169  169          # Time Quantum
 170  170          #
 171  171          QUANTUM=110
 172  172  .fi
 173  173  .in -2
 174  174  
 175  175  .sp
 176  176  .LP
 177  177  The value of the QUANTUM represents some fraction of a second with the
 178      -fractional value determied by the reciprocal value of RES. With the default
      178 +fractional value determined by the reciprocal value of RES. With the default
 179  179  value of RES = 1000, the reciprocal of 1000 is .001, or milliseconds. Thus, by
 180  180  default, the QUANTUM value represents the time quantum in milliseconds.
 181  181  .sp
 182  182  .LP
 183  183  If you change the RES value using \fBdispadmin\fR with the \fB-r\fR option, you
 184  184  also change the QUANTUM value. For example, instead of quantum of 110 with RES
 185  185  of 1000, a quantum of 11 with a RES of 100 results. The fractional unit is
 186  186  different while the amount of time is the same.
 187  187  .sp
 188  188  .LP

 189  189  You can use the \fB-s\fR option to change the time quantum value. Note that
 190  190  such changes are not preserved across reboot. Please refer to the
 191  191  \fBdispadmin\fR(1M) man page for additional information.
 192  192  
 193  193  .SH SEE ALSO
 194  194  .LP
 195  195  \fBprctl\fR(1), \fBpriocntl\fR(1), \fBdispadmin\fR(1M), \fBpsrset\fR(1M),
 196  196  \fBpriocntl\fR(2), \fBproject\fR(4), \fBresource_controls\fR(5)
 197  197  .sp
 198  198  .LP
 199  199  \fISystem Administration Guide:  Virtualization Using the Solaris Operating
 200  200  System\fR

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX