From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ab217670704151026k6de961c0q1ecd0385c95772c7@mail.gmail.com> Date: Sun, 15 Apr 2007 13:26:09 -0400 From: "Devon H. O'Dell" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Re: [sources] 20070413: /rc/bin/cpurc.local In-Reply-To: <5d375e920704150106m5865747flb6ae25392f8744ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d375e920704150106m5865747flb6ae25392f8744ca@mail.gmail.com> Topicbox-Message-UUID: 48d5737a-ead2-11e9-9d60-3106f5b1d025 2007/4/15, Uriel : > 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