[coyotos-dev] sleep capability

[Jonathan S. Shapiro]

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.

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

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