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 _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
