From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: [sources] 20070413: /rc/bin/cpurc.local
From: "Russ Cox" <rsc@swtch.com>
Date: Sun, 15 Apr 2007 13:38:40 -0400
In-Reply-To: <9ab217670704151026k6de961c0q1ecd0385c95772c7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20070415173813.F08F71E8C26@holo.morphisms.net>
Topicbox-Message-UUID: 48f24162-ead2-11e9-9d60-3106f5b1d025

> Additionally, we can't assume it starts off. The value is never
> initialized in the C code, so it could be 0, 1, or 382355318. I'm
> assuming that kencc zeroes uninitialized variables in the text, but
> I'm not sure.

This is just not true.  Global variables in C are guaranteed
to be zeroed at program start time.

> Would be nice to know what it does exactly, and why on earth it uses
> /dev/reboot. Note that there is no way to check the state of the
> variable, so one has no clue if one is enabling or disabling
> 'coopsched', whatever it does this interface is clearly far from
> ideal.

True enough.  The toggle was only so it could be turned off
easily if it was a bad idea, and so that the difference could
be measured.  But it turned out to be a good idea and I never
got around to removing the cruft.  The cruft is now gone
from sources.

The code it controlled in the scheduler did the following.
If process A readies process B to run (say, by writing to a pipe
that process B is reading) and gives up the cpu before
its time slice is up, then process B inherits the rest of
process A's time slice.

This makes concurrent programs (like pipelines, but also 
threaded programs that do a lot of context switching)
get something closer to their fair share of the cpu when
there is scheduling contention.  Inspired by L4.

Russ