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

["Devon H. O'Dell" <devon.odell@gmail.com>]

2007/4/15, Uriel <uriel99@gmail.com>:
> On Sat, 14 Apr 2007 06:17:24, 9changes@cat-v.org <9changes@cat-v.org> wrote:
> >         + # turn on cooperative scheduling (assuming it starts off)
> >         + echo coop > /dev/reboot
> >  [geoff] --rwxrwxr-x M 121 geoff sys 448 Apr 13 18:06 rc/bin/cpurc.local
>
> What does this do? It is undocumented, and as far as I can tell it
> toggles the coopsched var, which is used once in the scheduler code.

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.

> 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.
>
> While investigating this I noticed a couple of other undocumented
> commands for /dev/reboot that seem more relevant and self-evident but
> would still be nice to have documented.

At least this one, as the comment states, turns on cooperative
scheduling. Cooperative scheduling differs from preemptive scheduling
in that it requires the process to schedule itself, instead of rely on
the kernel to preempt it when something of higher priority needs to
run. Only, it seems that the kernel controls this, too.

In runproc() (port/proc.c), we have the test

if(coopsched && (p=m->readied) && p->mach == 0 && p->state==Ready &&
runq[Nrq-1].head==nil && runq[Nrq-2].head == nil)

m->readied is a ready process in the Mach structure. This is set in
ready(), which is called in various places, including when notes and
whatnot are sent to a process so that they can act on them
immediately.

p->mach is a pointer back to a machine structure. I'm assuming this
only gets set when a process is being run. I suppose this test is here
in case another CPU took over running the process.

Additionally, the check requires that the highest two priority run
queues are empty. If all these conditions are satisfied, we'll
schedule the process cooperatively. It seems like this would allow
low-priority processes that have notes to be delivered, or are stuck,
or similar, to run when other workloads have finished and the
scheduler hasn't yet ticked. This would obviously give potentially
better CPU / workload utilization. Which is I guess, what this means.
Seems like Russ wrote it, so it'd be interesting to hear how far off I
am.

> Best wishes
>
> uriel

--dho