[coyotos-dev] Impact of checkpointing on mobile systems

[Jonathan S. Shapiro]

On Fri, 2007-07-06 at 05:27 +0200, Pierre THIERRY wrote:
> It just occurred to me that checkpointing should make impossible something
> that is quite vluable on any mobile system when it operates on battery,
> that is shutting off the disk when it's not needed.

I think there is a win, but I think it is more subtle than this.

The problem in power management, generally, is that you have:

  (a) limited device information -- manufacturers will not
      disclose much of what you want
  (b) limited predictions (no "oracle")
  (c) strongly quantized choices

As an example of [c], take your case of turning the disk off. The major
cost here is in spinning the disk back up. If you had either good
prediction or good schedulability of disk usage, you would know whether
to (1) spin the disk down, or (2) keep it spinning -- which might be
cheaper.

Checkpointing becomes interesting here in three regards:

  1. The seek costs tend to be localized (therefore lower energy)
     in your scenario. You are modifying stuff, but you aren't modifying
     *new* stuff, so you will tend to remain entirely within the log
     area.

  2. You can write to flash store and then write to disk less often.

  3. You can checkpoint less often, which is essentially what Linux does
     by running bdflush less often.


Unfortunately, checkpointing *only* impacts write behavior, and the
major driver of disk accesses is read behavior. This suggests that
prefetching is pretty important. I don't know of any good studies on
that.

I'll close by noting that good prefetching in KeyKOS/EROS/Coyotos is
challenging, because the level of abstraction of the disk store is very
low. We don't know, at that level, all of the pages associated with a
given file, for example.



shap