[OLPC-devel] Linux resume time on iPAQ (Linux resume can be *really* fast).

[Jim Gettys]

The iPAQ is by far the closest device we have to modeling the OLPC
system, though the one I chose is less than 1/2 the integer performance
of our machine. It has roughly comparable peripherals to the OLPC
system, and unified graphics as the Geode (just a dumb frame buffer on
the SA1100).

Here's the test:

I have a simple C program written for me by Joshua Wise that just writes
characters to /dev/tty.  It can either do so continuously, or open and
close the device between each character.  In the former case, you get
metronome like character output, as the characters are all interrupt
driven out of the kernel character buffers; in the latter case, the
close/open sequence enables the operating system to reschedule the
process as it sees fit.  This is a much more interesting test.

I reconfirmed the data with Mike Bove this afternoon.

A: suspend on the iPAQ is amazingly fast; we could see no significant
delay from emitting a character to power off of the machine.

B: resume is also very fast, if not quite so fast (of order a few up to
10 milliseconds).

Here's the the measurement methodology:

I suspend the iPAQ.

I wait some amount of time.

I resume the iPAQ.  Conveniently, there happens to be a debug message
emitted by the bootloader right when it transfers control to Linux.

1) The iPAQ does nothing for anywhere between 280-400ms after resume
starts; we do not know (or care) what the cause actually is. We theorize
that it has some built in delay on how long the power supply takes to
stabilize or some such strangeness.   This will be a combination of
whatever hardware delays force us + any bootloader/BIOS delays.

2) within some few milliseconds of actually resuming (like of order 10
ms), Linux is in user space executing code, and some characters again
appear on the serial port.

3) There then appears to be an approximately 180ms gap before characters
again start appearing on the output port.  

The resume is triggering processes in user space; if I kill the cardmgr
process, used for hotplug of PCMCIA, this gap goes away.  There may be
very simple solutions too: e.g. running those processes at reduced
priority, but probably better is to try to arrange hotplug to work in
some other fashion.

Conclusion
==========

Linux can resume *really, really, really* fast, if the hardware lets it,
and the device drivers don't have bad delays built into them.  

If they do have such bad delays, we might have to do Mark's fast
suspend/resume scheme, or something driver specific. I really like
Mark's fast suspend/resume idea, and on some big systems (or with really
bad hardware that has multiple very long delays, it may be a godsend). 

We *will* have to do something about this user space behavior, which is
not at all surprising. One option might be to only attempt hotplug when
the lid is closed, or when you invoke some application, rather than on
resume from save to RAM; or it may be possible to do this on USB
provided hotplug events (but I haven't read the Geode errata sheet for a
while).

So: 
  o we need to vet the drivers we are using to see if any of them have
long built in delays on resume.  If our hardware is really braindead, we
might still have to do something about parallelizing the resume code.
The most likely driver to have problems with is clearly going to be USB,
and we need USB to talk to the Marvell chip.
  o The iPAQ is running Linux 2.4 which does not have a
particularly decent scheduler; it doesn't follow that we'll necessarily
see the same complete starvation of the original process (though we very
well might). We certainly don't want to be triggering hotplug at the
rate we'd like to suspend/resume.

Next step: perform the same tests on the OLPC system and see what that
tells us.  This is just now to the point of becoming feasible.
                               Regards,
                                 - Jim

-- 
Jim Gettys
One Laptop Per Child