[X-Unix] limit cpu usage

[William H. Magill]

> On Nov 25, 2004, at 11:14 PM, Brian Medley wrote:
>> On Wed, Nov 24, 2004 at 11:41:08PM -0500, William H. Magill wrote:
>>> On 24 Nov, 2004, at 20:29, Brian Medley wrote:
>>>> I've googled around, but haven't found an answer to this
>>>> question.  I would like to limit the max % cpu a process can
>>>> have.  Something similar to ulimit; however, ulimit only allows
>>>> limiting the number of cpu seconds a job can run.
>>>
>>> This is not philosophically possible on a Unix system.
>> ...
>>> The reason is a long discussion of Operating System theory, but 
>>> briefly
>>> put, Unix simply does not have the "hooks" necessary to implement any
>>> useful kind of Resource Control.
>>
>> Interesting, if you feel like writing more about the subject I'd
>> like to know.

First off, remember that there is Unix(tm) and there are a plethora of 
"unix" operating systems. (Which, as Linus Torvalds constantly reminds 
people, does NOT include Linux, "Linux is not Unix.")

Basically, the standard Unix job scheduler does classic, time-sharing, 
"round robin" service of individual processes. Each process gets a "CPU 
quantum" (timeslice) to use, unless it quits using that quantum early 
(such as to fire off an I/O or perform some other system call); then 
the next "ready to run" process gets a quantum to execute. There are 
priorities and other subtleties, but, as Eugene Lee pointed out, the 
unix priority system is not absolute. [Preemptive multi-tasking allows 
the scheduler to "preempt" a running process, even though it could 
effectively "use another quantum" and continue running (a CPU bound 
task). This is one big difference in the schedulers between OS9 and OS 
X.]

This is also why unmodified Unix does not support real-time activities 
... you cannot guarantee that any given event will receive timely 
attention.  The goal of the Unix scheduling algorithms is to keep the 
CPU active at all times. (Some versions even have an "idle instruction" 
to execute when nothing else is "runable.")

Put another way, the classic Unix scheduling algorithm is "CPU 
centric," not process or class centric. It is trying to keep the CPU 
busy at all times.

Solaris and Tru64 Unix, like AIX and the other proprietary Unix 
versions, have added hooks over the years to allow third parties to 
write job scheduler (class scheduler) add-ons for their OS. The work on 
Solaris and Tru64 was done around 98 or 99 in support of the same 
product (whose name I don't recall at the moment). AIX, did it for a 
different vendor as I recall.

 From the End User's point of view, these products effectively replace 
the standard Unix job scheduler with one using a different algorithm 
supporting many different parameters which more closely resemble the 
resource management systems (now called Workload Management by HP) 
found in other "proprietary" operating systems, like DEC's VMS and 
IBM's OS/360.  These resource management systems allowed, and in fact 
required, the System Operator to define "policies" -- "partitions," CPU 
or memory percentages and similar things -- for each individual process 
(or class) running on the system. These are the same kind of "policy" 
decisions which must be made for IP routers with "policy based routing" 
structures. IPv6 continues this trend with things like the Quality of 
Service (QOS) parameter.

Tru64 and OSX are both based on the Mach kernel, and the kinds of 
modifications (hooks) necessary for implementing a "class scheduler" 
mostly involve the addition of counters for all of the things that are 
going to be involved in controlling the processes. The "process control 
block" gets expanded and new tools are developed to modify and display 
things like "class" or whatever other parameter is being "controlled."

Not totally unrelated to this is the inclusion in Tiger of ACLs -- 
Access Control Lists.

Today, Apple is not "really" after the Enterprise Computing market. 
While powerful, Apple's hardware is still "not that big." Apple just 
has its toe in the water with its 2x "multi-processor" SMP systems. As 
they move upwards to 4x, 8x, 16x SMPs and as the new Power-5 "SMP on a 
chip" architecture rolls out, they will of necessity, change the 
capabilities of the OS X scheduler. Even today, Apple's SMP technology 
leaves a lot to be desired. True SMP, where any give INSTRUCTION, not 
just a process, can execute on any available CPU, is hard. [Clusters 
are a whole different animal and basically unrelated to this 
discussion. They have, "yet another scheduler."]

If you Google for "unix scheduler" you will find a number of papers on 
the topic. It's still a "hot" Computer Science topic.

T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard - 768 Meg
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg]- Tru64 5.1a
# XP1000  [Alpha EV6]
magill at mcgillsociety.org
magill at acm.org
magill at mac.com
whmagill at gmail.com