[linux-pm] Re: no partial-tree suspends

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> > > > Well, for example disk driver certainly needs interrupt controller and
> > > > timer devices to be working... Disk itself does not care about timer
> > > > devices, but driver certainly needs them.
> > > >
> > > > And it is this kind of dependencies that would make it "interesting".
> > >
> > > I'm not disputing those dependencies, but there seems to be something
> > > wrong. If we're writing the image with interrupts enabled, we've either
> > > not suspended the system devices (which means we're not saving their
> > > state), or we've re-enabled interrupts (which may cause some bad things if
> > > some system devices are disabled). If we're writing with interrupts
> > > disabled, then the timers and IRQ seem to be irrelevant. What am I
> > > missing?
> >
> > Currently, we always freeze/unfreeze the whole tree. (We write with
> > interrupts enabled). We do not see any of these issues.
> >
> > Someone suggested that we should only unfreeze swap device. That does
> > not work, see above.
> 
> Why not? The suspend/resume walks of the tree don't touch system devices,
> which includes the set of interrupt controllers, timers, etc. It should
> work fine.

Okay...

During unfreeze we need to start at least all system devices and
ancesors of swap and console (for debugging). We probably could get
away with leaving some "normal" devices frozen.

OTOH it would only complicate things for a very little gain in
speed. In particular it would not make USB host controller code
simpler (need to handle usb mass storage, anyway). Code to find out
which device coresponds to swap partition is not going to be trivial,
either.

I'm not going to implement partial-tree unfreezes. Whoever is going to
implement them should better have some convincing benchmarks to prove
that added complexity is worth it. I believe that doing fast
freeze/unfreeze is superior to partial-tree stuff (and that's what we
are doing in suse kernel and what we were doing in 2.6.9-rc3-mm3 or
so) -- only slow operation during freeze is spindown, and that can be
avoided *very* easily.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux