Re: [9fans] Re: [sources] 20070413: /rc/bin/cpurc.local

[Uriel <uriel99@gmail.com>]

Neat, thanks for the explanation!

uriel

On 4/15/07, Russ Cox <rsc@swtch.com> wrote:
> > 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
>
>