[coyotos-dev] sleep capability

[Valerio Bellizzomi]

On 28/01/2007, at 11.19, Jonathan S. Shapiro wrote:

>On Sun, 2007-01-28 at 15:23 +0100, Valerio Bellizzomi wrote:
>> On 27/01/2007, at 22.45, Jonathan S. Shapiro wrote:
>> 
>> >On Sun, 2007-01-28 at 00:53 +0100, Valerio Bellizzomi wrote:
>> >> >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.
>>
>> Oh ok, yes, what I meant is a single-cpu schedule in this case
>> specifically: when a cpu intensive program goes into a so-called
>> "coffe-break" time of low cpu usage, it donates its slice.
>
>That is not what we mean by slice transfer or slice donation. Both of
>those terms have to do with IPC. What you are describing is merely the
>normal behavior of the scheduler.

Somewhere I forgot that there is a scheduler.

>
>Problem is: if my process wants to run only on CPU A, and your process
>gives up CPU B, it doesn't help me.

What is the behavior in the case that both processes want to run on CPU A
?

>
>The more complicated case is processes that say "I don't care what CPU I
>run on". It is simple to implement this in the scheduler, but there is a
>substantial cost to migrating the process that must be considered. As a
>rough model, that cost is something like:
>
>  T.migrate + k(T.now - T.runout)
>
>where the second term is approximating the amount of surviving cache
>residency that must be migrated. A good measure is actually more
>complicated than this, even, because it would consider gang scheduling.
>But basically, if
>
>  T.migrate + k(T.now - T.runout) < (T.now - T.nextLocalSlice)
>
>then *maybe* the thread should migrate to the new CPU.
>-- 
>Jonathan S. Shapiro, Ph.D.
>Managing Director
>The EROS Group, LLC
>+1 443 927 1719 x5100