suspend/resume timings

[Jens Axboe]

On Mon, Apr 02 2007, Marcelo Tosatti wrote:
> On Sun, Apr 01, 2007 at 09:09:19PM +0200, Jens Axboe wrote:
> > Hi,
> > 
> > I took a look at the time spent doing a suspend and resume cycle. In
> > general things go pretty fast, most devices handle it really quickly.
> > USB is a bit slow (~100 msec), but I ignored that since apparently there
> > are already people working on fixing USB suspend (functionality, speed
> > of course comes second).
> > 
> > The slowest parts are the keyboard and mouse. psmouse takes ~570 msec to
> > resume alone, and the keyboard is no speed daemon at ~269 msecs. Looking
> > at the psmouse first, by far the majority of the time is spend resetting
> > the device (drivers/input/mouse/olpc.c:olpc_reconnect() ->
> > psmouse_reset()). A quick test works fine for me without the reset, but
> > that may not be a sound approach. Perhaps deferring a reset to IFF
> > olpc_get_model() fails would be more safe?
> > 
> > I'll be playing some more with the timings and testing over the next
> > week, do let me know if there's something more urgent in suspend/resume
> > area that needs attention.
> > 
> > The kernel used was current olpc-2.6.
> 
> Jens,
> 
> What about this patch instead. It avoids the psmouse reconnect method
> from being called (thus the ps2 command in olpc_get_model()), which
> saves us a few more milliseconds.

If you want my honest opinion, I think it's a big hack. If the keyboard
and mouse are always connected to a live power rail, what makes
reconnect so special? We should just fix the suspend/resume hooks for
mouse and keyboard to do only the minimal bits, if anything at all.

-- 
Jens Axboe