On Nov 20, 2009, at 9:29 AM, Enrico Zini <enr...@enricozini.org> wrote:
> On Fri, Nov 20, 2009 at 08:03:33AM -0600, Victor Lowther wrote: > > [...] >>> 00powersave resume... result: 0 2.062235sec >>> 00logging resume... result: 0 0.554852sec >>> 00auto-quirk resume... result: 0 0.732000sec >> >> Woah, shell scripts do not perform well at all on openmoko -- those >> times are at least 3 orders of magnitude slower than our usual x86 >> laptop platform. Which shell are you using as /bin/sh? > > Admittedly, that run used bash, which didn't help. I've redone the > timings with dash, which improves the situation but not dramatically: > > 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. > >>> Only, I'd like the standard to stay in sync. I've had to pick an >>> extra >>> special exit status to implement "cancel resume", and it might be >>> a good >>> idea if we eventually standardise it, so that the proper pm-utils >>> don't >>> pick it in the future for something else, forcing all scripts that >>> use >>> that feature to be rewritten. >> >> I do not have a problem with standardizing on exit code 250 as cancel >> resume. > > Excellent. Feel free to pick a better number: I picked 250 pretty > much at random. If we follow the sequence that I found in pm-utils > 1.2.5, picking CA=251 would not leave a hole: > > NA=254 > NX=253 > DX=252 > CA=251 > > I'm fully open at this stage, so I leave it up to you to decide. > > > Ciao, > > Enrico > > -- > GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> > _______________________________________________ > 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
