[SHR] Suspend / Resume speed
Michael 'Mickey' Lauer
mickey at openmoko.org
Wed Feb 25 19:30:24 CET 2009
Am Mittwoch, den 25.02.2009, 19:05 +0100 schrieb Florian Hackenberger:
> On Monday 23 February 2009 12:08:10 Michael 'Mickey' Lauer wrote:
> > Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger:
> > > I noticed that suspending / resuming on 2008.12 is quite fast compared
> > > to SHR. The difference which is most noticeable is that SHR switches to
> > > a virtual terminal before and right after suspending, as opposed to
> > > 2008.12 which resumes right into X.
> > Chances are they just cover up by turning backlight off prior to doing
> > real suspend and then wait until resume has happened before turning it
> > on again. We're not doing this yet, since we had our share with
> > suspend/resume problems in the past and only will do that once it proves
> > 100% solid.
> I don't think that they simply disable the backlight. Resuming from SHR
> unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes
> under 3 seconds. While this is not a scientific measurement, 2008.12 surely
> is a lot faster. Any other ideas what they do differently?
No idea, sorry. I have never seen 2008.12. It's definitely not a problem
in the base system, since FSO ms5.1 resolves in 1 second (admittedly,
with Qi, with U-Boot it might be 2 seconds).
> > > Is there a way to replicate this
> > > behaviour on SHR? I suspect that we could save at least a second
> > > resume time, because printing and scrolling a few hundred lines of
> > > kernel log in addition to the mode switches takes a bit of time.
> > IIRC Garmin had a patch in their Navi sources that removes switching
> > VT on suspend/resume, which gave a) a better user experience and b)
> > small speedup. We should pick that up IMO.
> It should be easier to copy from 2008.12 shouldn't it?
No, 2008.12 certainly has no kernel patches like that.
More information about the community