Re: shrinking memory for suspend?

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

 



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.
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[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