[coyotos-dev] sleep capability

[Valerio Bellizzomi]

On 27/01/2007, at 10.52, Jonathan S. Shapiro wrote:

>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.

This sounds very good for control of CPU allocation, specifically if we
want to dedicate one CPU to one task. But read on...

>
>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).

This is an ability that we want in any case. It gives some more control to
a user-land admission control agent...

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

Probably Yes, so that we can take advantage of slice transfer.

>
>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.

For processes that do not care we can use opportunistic, for processes
that actually do care, we can use the other one.
In my view, processes that fall in the normal class and "interactive"
category (like word processors and the like), generally do not care where
they make progress.
On the other hand, most CPU-intensive processes generally do care.

>
>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
>
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev