On Sun, 2005-10-30 at 23:20 -0600, William Grim wrote: > I haven't thought about all the details, but in my mind you would just > have to have some way to store all the process (task) contexts > (servers+data/registers) as they run and keep checkpointing them.
This is basically right. The trick to it is to ensure that all of the definitive kernel data structures are easy to export. By "definitive", I mean "any state that the kernel cannot easily reconstruct". > if this happens frequently doesn't this > greatly reduce performance? > > I don't know how KeyKOS/EROS handle persistance, but I'm quite curious > how they do it without providing lots of overhead due to overloading > the bus bandwidth (i.e. IDE, SCSI, etc). Ruud was asking about excessive checkpoint frequency. In answer to your answer, the issue isn't bus bandwidth; it's sustainable disk throughput **at the disk**. Overall, checkpointing does better at using and managing this than conventional file systems. For the full story you really need to look at the paper, but here is a hint: the two ideal conditions for I/O are (1) linear, and (2) sortable bulk. Essentially *all* checkpoint-related I/O meets one of these two conditions. No compression is used. This would actually make matters much harder, because it would have the effect of making block sizes variable. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
