Re: Scheduler activations (IIRC) question

[Jamie Lokier <jamie@shareable.org>]

Mike Fedyk wrote:
> On Sat, Aug 16, 2003 at 12:03:12AM +0100, Jamie Lokier wrote:
> > I think it's been done before, under the name "scheduler activations",
> > on some other kernel.
> > 
> 
> Wouldn't futexes help with this?

Futexes are great for the waking up part, not so great for putting
another task to sleep :)

I see two ways to use a futex.

   1. Active task changes a synchronisation word.
   2. Active task FUTEX_WAKEs the shadow task before syscall.
   3. Syscall.
   4. Active task restores synchronisation word.
      ..time passes..
   5. Shadow task runs.
   6. Looks at synchronisation word, which says "go back to sleep".
   7. Shadow task sleeps with FUTEX_WAIT.

This isn't bad, except that a shadow task runs every time we do a
potentially blocking system call from the active task, _or_ is often
ready to run.

If it's just often ready to run, that's not a problem.  If it always
runs immediately, that's two unnecessary context switches per system
call; quite an overhead, and I might as well hand off system calls to
helper threads in that case :)

Next way is the same, except that control is always handed to the
shadow task and the active task, when the system call is finished,
queues the current state machine for the shadow task to pick it up and
then sleeps.  Effectively the active and shadow tasks swap roles on
each system call.

This may or may not be better, depending on whether we've reduced the
average number of context switches to 1 or increased it to 1 :)

It'd wreck the kernel scheduler's interactivity heuristics, too :):)

The first futex method would be quite efficient if a variant of
FUTEX_WAIT was clever enough not to need to be scheduled just to go
back to sleep when the word has the "go back to sleep" value.

Third way is just to use SIGCONT and SIGSTOP.  Not the fastest, but
perhaps faster than the futex-induced context switches.  It'd need to
be measured.

None of these will work well if "wakee" tasks are able to run
immediately after being woken, before "waker" tasks get a chance to
either block or put the wakees back to sleep.

-- Jamie