[coyotos-dev] sleep capability

[Jonathan S. Shapiro]

On Sat, 2007-01-27 at 09:27 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 22/01/2007 hora 10:19:
> > 2. Running a second thread on a concurrent CPU is good enough to get a
> > very high accuracy clock.
> 
> It occurred to me that it's indeed a very useful feature to be able to
> have two threads or processes scheduled on different CPUs. Will
> processes give the scheduler some hints like it will be the case for the
> virtual memory pager?

We do not yet have a final answer for this. Here is the current
thinking, but this will probably change -- scheduling is the biggest
open issue in Coyotos at the moment.

The question you are really asking is: what is the meaning of a schedule
capability? Our preference is that a schedule capability binds a process
to a specific CPU. A process wishing to change its CPU must establish a
schedule on the new CPU and then store that capability into its
scheduling slot.

There are problems with this approach, but let me start with the
rationale:

On a single-CPU system, there is almost no reason to do kernel-level
threading in Coyotos. Since you can only execute one instruction at a
time on the real CPU, the activation mechanism provides as much
concurrency as you are ever going to get.

On a multi-CPU system, more concurrency is available, but it comes at
the cost of a kernel-level thread (and the complexities that go with
that). In order to actually *gain* from this concurrency, that second
kernel thread generally needs to be scheduled on a second CPU. This
means that we want the ability to "place" processes on their CPUs, and
the most sensible place to do this is with the schedule capability
(which represents the binding of a process to a compute resource).

So now the question is: do we *also* want a scheduling mechanism that is
more opportunistic, using whatever slice is available wherever it
appears?

I suspect that the answer is going to turn out to be "yes" for two
reasons:

  1. The exception to my statement about activations is sender-side
     blocking. If you block while transmitting a message, the whole
     process blocks.

  2. Some processes really just want to make progress and do not care
     where. This is especially true for single-threaded processes.

In a way this is unfortunate, because building multi-CPU schedules is
actually much harder to do.

I suspect that in the end it is necessary.

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100