On Fri, 2009-11-20 at 19:00 +0000, Enrico Zini wrote: > On Fri, Nov 20, 2009 at 10:43:46AM -0600, Victor Lowther wrote: > > > > 00auto-quirk suspend... result: 0 0.759016sec > > > 00logging suspend... result: 0 0.547586sec > > > 00powersave suspend... result: 0 1.407290sec > > > 49bluetooth suspend... result: 254 0.397464sec > > > 55NetworkManager suspend... result: 254 0.683650sec > > > 55wicd suspend... result: 252 2.642522sec > > > 75modules suspend... result: 254 0.520231sec > > > 90clock suspend... result: 254 0.397052sec > > > 94cpufreq suspend... result: 0 0.613860sec > > > 95led suspend... result: 254 0.066354sec > > > 98smart-kernel-video suspend... result: 254 0.428706sec > > > 98smart-kernel-video resume... result: 0 3.605227sec > > > 95led resume... result: 254 0.060935sec > > > 94cpufreq resume... result: 0 0.490641sec > > > 90clock resume... result: 254 0.567018sec > > > 75modules resume... result: 0 0.852448sec > > > 55wicd resume... result: 252 3.540225sec > > > 55NetworkManager resume... result: 254 0.560339sec > > > 49bluetooth resume... result: 254 0.599266sec > > > 00powersave resume... result: 0 1.802375sec > > > 00logging resume... result: 0 0.405285sec > > > 00auto-quirk resume... result: 0 0.427392sec > > > > Still, that is really slow. Most of those resume scripts are noops, > > so that half a second run time indicates that it is taking half a > > second to spawn each hook, even when everything should still be in > > cache. > > Yes, I think it takes quite some time to source pm-functions. In that > list you can see that 95led, which does not source pm-functions, takes > one order of magnitude less to run. > > What do you mean with "everything should still be in cache"? If you mean > that pm-functions are supposed to be source at the beginning only, then > it's not happening with my pm-utils "light", since it is implemented in > C. But I don't think that is the case, since pm-utils in run_hooks > doesn't source the hooks, but executes them as well.
I simply meant that the files should still be in the buffer cache, executables should be in memory, etc. -- the main source of latency running pm-utils with /bin/dash on a laptop is pretty much how fast we can read the data off the hard drive and how long it actually takes the kernel to enter and leave S3. Taking half a second to source /usr/lib/pm-utils/functions is a little crazy -- all it is doing is defining functions. > If you mean the CPU cache instead, then nope: the CPU of the FreeRunner > throws away the whole cache at every process switch. nah, I was talking about buffer cache. > > Ciao, > > Enrico > > _______________________________________________ > Pm-utils mailing list > Pm-utils@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pm-utils _______________________________________________ Pm-utils mailing list Pm-utils@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils
