[coyotos-dev] Sleep, wakeup, and persistence

[Jonathan S. Shapiro]

On Fri, 2007-09-14 at 20:49 +0100, Sam Mason wrote:
> On Fri, Sep 14, 2007 at 02:03:51PM -0400, Jonathan S. Shapiro wrote:
> > I want to document a discussion JWA and I had yesterday. This solution
> > is probably well known; it just wasn't well known to us.
> 
> Our last discussion of time[1] had the kernel stripped of almost all
> time related functionality.  Is that still the intention, or have things
> changed?

This was my original intention, but it isn't going to work. Drivers that
are outside of the kernel need to be able to sleep for very short
intervals. The addition of a user-mode agent in these sleeps can in some
cases introduce prohibitive overhead.

BUT:

It doesn't really matter. Whether there is one sleeping application or
many actually does not change the required kernel interface.

> 
> If that is still the case then this is how I see it.
> 
> > A process wants to sleep until time X. That is easy if the system keeps
> > running until then, but if the system re-starts what happens?
> > 
> > There are two concerns here:
> > 
> >   1. The underlying system may not have a monotonically increasing
> >      clock. Many embedded systems do not.
> 
> What sort of things would these devices have to wait for?  I'd assume
> that if they don't have any sort of real time clock, they wouldn't want
> to wait until some specific real time---at least not until somehow
> determining what the real time is.  They're probably only interested in
> sleeping for short amounts of time to keep timeouts and such working.
> If that's the case then knowing the real time doesn't matter at all.

In the presence of checkpointing, I believe that the only correct
handling of relative sleeps (sleep for K units of time) is to turn them
into absolute deadlines. To enumerate the possibilities, we have:

  1. Cancel all such sleeps on restart.
  2. Convert these sleeps to absolute deadlines so that we know
     which ones have not ended yet at the time of restart.
  3. Allow the sleeps to replay, with the effect that the sleep
     may run for a much longer time than intended.

In the driver case, the driver *must* know that a restart has occurred,
because various hardware state machines have been reset. If the drivers
are non-persistent, all is well, but for persistent drivers there is a
serious design challenge here.

> There seem to be two use cases to me; that of sleeping for a short
> amount of time, and that of sleeping until we reach some specific real
> time.  Why not put the first in the kernel, and leave the second up to
> userspace to implement.

The most natural implementation of "sleep until absolute time" is to
convert into "sleep until absolute system time unit". Unfortunately, the
kernel probably *does* need to know how to convert intervals of the form
"k microseconds" into intervals of the form "k fundamental time units".

It was never my intention that the kernel should understand absolute
time in human terms. It was only my intention that the kernel should
understand absolute time in terms of fundamental system time units in
order to be able to establish a sort on deadlines, and also in order to
determine whether sleep cancellation is required.

shap
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org