Newsgroups: comp.os.minix
Subject: Re: Clock Task
References: <Pine.GSO.4.10.10005221114460.27371-100000@sandman.ucdavis.edu>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <39298476@news.isc.rit.edu>
Date: 22 May 2000 15:03:18 -0500
X-Trace: 22 May 2000 15:03:18 -0500, grace.isc.rit.edu
Lines: 64
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.mel.connect.com.au!news.syd.connect.com.au!nsw.nnrp.telstra.net!intgwlon.nntp.telstra.net!newsfeed.mathworks.com!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.oz.au comp.os.minix:35294

In article <Pine.GSO.4.10.10005221114460.27371-100000@sandman.ucdavis.edu>,
Mikhail Amchislavsky  <mamchisl@mailbox.ucdavis.edu> wrote:
>I'm trying to make the scheduler more efficient.
>For this I'm doing some tinkering.
>
>I've been trying to find the amount of ticks used by
>the clock task relative the all others. I'm not sure
>if I'm getting the right numbers. Logically the clock
>task should use almost every other tick, right?

I haven't investigated it recently (or in much depth), but I doubt that
it is (easily) possible to determine how much time is used by the clock
task.  (Why?  because the clock task is synchronized to the clock which
is also used to generate the accounting.)  If the clock task itself has
the job of updating the accounting information, then it would appear to
use *all* the clock ticks.

If, on the other hand, the interrupt handler updates the accounting, it
would appear that the clock task would just about never run (as it, for
the most part, should never take a full quanta to run).

The best approaches are to either (a) use some other, independent timer
to get profiling information (and only to get such information), or (b)
use a logic analyzer with appropriate software, etc.  Approach (b) does
cost considrably more, of course, but can give really detailed info.

>No about boosting the scheduler. I figure I should make
>the clock task run more often. I've tried changeing
>the quantum size, but since I don't know if I'm getting
>proper readings of non clock task ticks, I'm not sure
>if this is working.

I'm a bit confused by what you are trying to do.  If you are making the
time quantum of processes longer, the scheduling code will run less and
the effeciency will be a bit better (but the response time of a heavily
loaded system will be worse).  Making it shorter will have the opposite
effects, at least up to a point.

Since the minix scheduler is very simple, it does not take long to run;
and since a couple of context switches happen at just about every clock
tick (into the clock task, and back out), not running it would probably
not have a noticible impact on total performance.

(Cache size does also come into play here; if the cache is too small to
hold the clock code and process code, the above is true.  If it is huge
and can contain most of the working set of all active processes it also
is true.  If it is of a medium size, able to hold the active set of the
clock task and of the current process but not all active processes then
the frequency of switching processes may have a noticible impact on the
overall system speed.)

>If anyone knows, could you give me a relative ratio of
>clock task ticks to all clock ticks.

In my experience, the worst bottlenecks in Minix are with I/O; but that
may change with different hardware (I run MacMinix on a Mac SE, perhaps
the rough equivalent of a fully loaded AT system in terms of power).

>Thanks
>
>Mik 

Hope this helps some,
-- Andrew Erickson
