Ladies and gentlemen, please welcome Solaris 10! Go here to download an official production release. It's FREE, so what are you waiting for? :-)

In pre-Zones era, the Fair Share Scheduler (FSS) was used to control how many CPU cycles are assigned by the system to active applications or workloads. The administrator could create projects to identify those workloads and assign CPU shares to them. The FSS scheduler, if used, would then guarantee that if these projects compete with each other for the same set of CPUs, each project would get a fraction of all CPU cycles that is proportional to the ratio between its number of shares and the total amount of shares given to all other active projects.

If processor sets were used, FSS would treat each processor set independently. That is, each processor set has its own total number of shares assigned to projects running on it. This is obvious because projects running on different processor sets do not (and can not) compete for the same CPUs.

In Solaris 10, when Zones were added to the mix, this behavior was preserved but we added as a "second level" (zone level on top of project level) scheduler. Shares can now be assigned to projects and zones. The more shares a zone has compared to other zones, the more CPU cycles will be assigned to projects that run inside it (if there's contention for CPU resources between the zones). The actual allocation of CPU cycles between projects in a zone is done the same way as before. Local zone administrator can divide CPU cycles between their projects, but cannot change the number of shares assigned to its zone, as this can only be done by the global zone administrator.

Now, if you want to use FSS to divide CPU cycles between zones, here's what you need to do. You can assign shares to zones permanently with zonecfg(1M), or change the assignment dynamically with prctl(1M). Both of these operations can be only done from the global zone. In the following example, zone "zone1" gets 15 shares statically assigned to it with zonecfg(1M):

global# zonecfg -z zone1
zonecfg:zone1> add rctl
zonecfg:zone1:rctl> set name=zone.cpu-shares
zonecfg:zone1:rctl> add value (priv=privileged,limit=15,action=none)
zonecfg:zone1:rctl> end
zonecfg:zone1> exit

This way, CPU shares will be automatically assigned to the zone at zone boot time. If the zone is already running, CPU shares can be assigned to it without rebooting by using prctl(1M):

global# prctl -r -n zone.cpu-shares -v 15 -i zone z1

To confirm that the number of CPU shares has changed, prctl(1M) can be used from within zone "z1":

z1# prctl -n zone.cpu-shares $$
process: 101439: zsh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
zone.cpu-shares
        privileged         15       -   none                                 -
        system          65.5K     max   none                                 -

As you can see there's an upper limit (set to 65535) on how many CPU shares can be assigned to a zone or a project. The absolute values don't really matter because CPU shares are only used in comparison. Assigning 10 and 20 shares to two projects will have the same effect as if they would get assigned 10,000 and 20,000 shares.

One very important detail. The FSS scheduling class is not enabled by default. That is, projects or zones will ignore the CPU shares information if they are not running in the FSS class. The FSS scheduler can be set to be the default scheduling class for the whole system by using the -d option for dispadmin(1M) and rebooting:

global# dispadmin -d FSS
global# reboot

If reboot is not desireable, then all processes can be manually moved to the FSS scheduling class by using priocntl(1M):

global# priocntl -s -c FSS -i class TS
global# priocntl -s -c FSS -i class IA
global# priocntl -s -c FSS -i pid 1

Note that we explicitly avoid moving processes running in RT (Real-Time) and FX (Fixed) scheduling classes. To verify that all processes are now running in the FSS scheduling class, you can run the following command and look at the 4th column:

global# ps -cafe
...
    root 101050 101039  FSS  59 17:14:59 ?           0:00 /sbin/init 
    root 101169 101167  FSS  29 17:15:07 ?           0:00 /usr/lib/saf/ttymon
...

That's it, really. If you need more information about FSS, then a good place to start is FSS(7). Next time I'll talk about another way of dividing CPU time between zones by using the Resource Pools feature in Solaris 10.

If you hate loud CPU fans in modern PCs as much as I do, then you might find this fanless heatsink interesting. The company that makes them is called Scythe, and they manufacture pretty cool traditional CPU heatsinks (with fans) as well.

There's also a review on Silent PC Review. The size of this fan really scares me.

Hi, my name is Andrei Dorofeev, and I am an engineer in the Solaris Kernel Group. I've been working at Sun for almost 6 years. I am currently working in the Resource Management team and spending a lot of my time dealing with various scheduling issues. Some of the things I've worked on in the past:

• prstat - utility to report active process statistics (ala top)
• Solaris Resource Manager 1.x - an extension to the Solaris Operating System (unbundled product for 2.6, 7, and 8), which is comprised of the Fair Share Scheduler, and additional resource controls.
• Solaris 9 Resource Manager - the same functionality as above (and more) is now part of the base OS. S9RM consists of the following components:
  • Projects, Tasks, and Extended Accounting - project provides a network-wide administrative identifier for a workload, and task collects a group of processes into a workload component.
  • Resource Controls - major extention to the UNIX per-process resource limit concept
  • Fair Share Scheduler - additional scheduling class that provides the ability to control the allocation of available CPU resources among workloads, based on their importance (in terms of shares).
  • Resource Pools - flexible configuration mechanism for creating groups of resource partitions and associating them with applications or services.
• Support for Intel's Hyper-Threading technology in Solaris 9.