A question about EROS

[shapj@us.ibm.com]

Renaud:

You are entirely right about the real-time issue.  On rereading, you could be
asking several different questions, though, so I shall try to answer all of
them.

** The first concerns the cost of the checkpoint action -- how long is the
system paused while the checkpoint is being taken?

The answer in the current system is that the interactive delay for a snapshot to
be taken is about 50ms.  This is higher than I would like, as 60 frames per
second requires that new frames be delivered every ~16ms.  Actually, it's not as
bad as all that; it simply means that one has to buffer 4 or 5 frames.  As I
have said previously, we have a design that will get us into the hundreds of
microseconds, which is good enough for all of the human interface apps that I am
aware of.

** The second concerns data mutation

It's possible that you are concerned about the cost of copy-on-write.  First
off, note that most of the data in question (video streams, audio streams) is
read-only.  Even if it is read-write, the *output* routine isn't mutating the
page, so it doesn't incur the copy-on-write cost.  The real question, then,
arises in the case where you are dynamically generating the data (e.g.
synthesized audio).  Let's do some arithmetic here, with the goal of learning
how much "extra" buffer we need to make up for checkpointing.

A 44Khz 16 bit audio stream takes 88Kbytes/channel/second, so figure 43
pages/second.  In the worst event, your audio data working set would need to be
double this, which isn't really that bad.  On a typical checkpoint, on a machine
with 96 Mbytes of memory, you'll have 64Mbytes to get out to the disk, which
takes about 5 seconds to do all told.  The important point is that few
applications have random mutate behavior, and EROS preferentially deals with
pages that applications are actively modifying.  Your chances are pretty good of
not missing the timing requirement.

** Finally: pinned pages

There is a paper design for something called a "working set"  pages within a
working set compete only against themselves for storage, and are therefore
effectively pinned.  This could certainly be augmented with an attribute that
says, in effect, "pages in this working set constitute temporary data that need
not be preserved across restarts"  It is not immediately clear if this should be
set for the entire working set or on an individual page basis.  The design
problem is that multiple parties might be using the page, and that they might
not agree on which "working set" owns the page.  If *any* user requires the page
to be stabilized, then the page must be stabilized.


Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 7595



Renaud Hebert <renaud.hebert@alcatel.fr> on 06/24/99 09:55:22 AM

To:   Jonathan S Shapiro/Watson/IBM@IBMUS
cc:
Subject:  A question about EROS





First let me introduce I'm a Unix developper but I do not claim at all
being an expert or konowing much about kernel development.

I've read about EROS a while ago and the message from Eric S. Raymondm
has made me think about it again, apparently he has been as impressed as
I was...
It looks very neat (it would be even better if the license was GPL or
the like but you are evidently the only one who can choose here).

But I thought about what can be a little problem with EROS: the
resynchronisation every 5 minutes, I think that it can be a problem with
real-time apps, or thinks that need to act without any interruptions
(playing/recording a movie for example).

I'm not sure that it is a real problem and would like to know what you
think about it.

Sure you could increase this resynchronisation period but this would
defeat the whole purpose of persistency...

Have a nice day.
__________________________________________________________________
Renaud HEBERT