Re: Attempted summary of suspend-blockers LKML thread

[Ted Ts'o]

On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore.... 

Part of the problem here may also be a naming problem.  There are
multiple reasons why you might want to block suspend, and it goes far
beyond what the CPU can do.

Let's give another example, from the laptop world.  If you close the
the MacBook, it "suspends".  That is, all processes stop, and the CPU
enters a sleep state.  Sounds just like Linux's suspend-to-ram, right?

Except for the fact that if you insert a USB cable connected to a
iPod/iPad/iPhone, the CPU wakes up, and iTunes will do a sync, and
then the machine goes back to sleep.  And if the Mail application is
in the middle of manipulating the IMAP mailbox, it will be allowed to
finish what it is doing, and then the system goes to sleep.

So in the case of both the MacBook, where the user has closed the
laptop, and in the case of Cell Phone, where the user has pushed the
button saying he/she's done working with the application, the _normal_
thing to do force all processes to go to sleep, and then let the CPU
go to sleep.

But, you may have applications that are specially privileged so they
can ignore the user command to suspend the machine.  Maybe it's an
iTunes-like situation, where in response to some hardware interrupt,
it's allowed to wake up, do its thing, and then go back to sleep,
allowing the hardware to go back to sleep.  Maybe it's a mail
application that wants to wakeup every 15 minutes, suck down any new
mail, and then go back to sleep.  The suspend blocker is a way to
achieve this --- and this has nothing to do with chip technology, but
with a specific use case.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/