[Pm-utils] Canceling resume

[Victor Lowther]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pm-utils