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
