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 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.
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.
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.