Re: shrinking memory for suspend?

[Paul Mackerras <paulus@samba.org>]

Alan Stern writes:

> > > Which is why the powermac/powerbook sleep code insists on there only
> > > being one cpu active.  I have an SMP powermac which can sleep; I use a
> > > little script to take the second cpu down before sleeping and bring it
> > > back up after waking up.
> > 
> > That's quite intrusive.  Ideally, user space processes should not notice that
> > there have been a suspend at one point.
> 
> What happens without preemption enabled when a device driver's suspend() 
> method calls schedule()?

That would be bad; don't do that. :)

In the context of the original powermac sleep code, drivers registered
a notifier for sleep which got called twice - the first time before
doing the sync, and the second time after it, with an argument to the
notifier to indicate which call this is.  Drivers are allowed to call
schedule on the first call but not on the second.

> With or without preemption enabled, what happens when a user process tries
> to do I/O to a suspended device?

If we have two calls to the driver, then the second one should happen
with only one cpu still active and preemption disabled, and that's the
call where the device hardware should actually be put into its suspend
state.

I'm not saying the original powermac code was perfect, but it does
work well for many users using powerbooks (which are all single-cpu
machines), without freezing processes.

I can see the attraction of the freezer, but there are still at least
three problems with it AFAICS:

* Working out which kernel threads should *not* be frozen is a manual,
  difficult and error-prone process
* Putting processes into an uninterruptible sleep stuffs up the load
  average
* It's intrusive in the sense that every kernel thread needs to have
  code in it to allow it to be frozen, and not all the kernel thread
  main loops have been "fixed".

Paul.