On Mon, 4 Jun 2007, Pavel Machek wrote: > > With the USB subsystem I have followed the approach taken by the PM > > core, which is that tasks are frozen. But one can -- and Linus has on > > at least one occasion -- make a good case that tasks should be left > > running while only I/O is frozen. This would require the subsystem to > > distinguish between a selective device suspend and a system-wide > > suspend-to-RAM, so that selective resume could be enabled on demand in > > one case but not the other. > > > > It's quite doable in principle -- it's just not the technique I used. > > I guess we need to do that. Random user should not be able to prevent > machine from sleeping. Just to be clear about this, let's agree that we're talking about suspend-to-RAM here, not hibernation. It boils down to whether we want to freeze user tasks. As I recall, Linus said that he didn't have any big objection to freezing user threads; he was much more concerned about freezing kernel threads. Thanks to Raphael's new notifier chains this will no longer be an issue, since kernel threads will be able to stop themselves when they receive a suspend notification. There may remain some obscure difficulties in discerning whether a particular thread should be classified as user or kernel, but let's ignore them. Even if we don't actively freeze user threads, approximately the same effect can be achieved in the following way: Change the main kernel entry points so that any thread performing a system call during a suspend will get frozen until the suspend is over. Threads that run entirely in userspace will continue doing useful work as before, and kernel threads won't be affected at all. (Not that I think it's necessary to do this; it's just a way to avoid freezing user tasks until they need it.) One way or another, freezing user tasks should not be a big deal. After all, once the suspend is complete eveything will effectively be frozen anyway. I suppose there might be issues involving tasks which need to run in order to complete the suspend -- IMO any such issues should be handled by carrying out the necessary actions before the point where we now start up the freezer. The alternative is to have drivers take over the burden. I don't like this at all. The most obvious disadvantage is that the necessary checks would have to be duplicated many many times and spread out over lots of drivers. It's also harder to handle these things at the driver level. Suppose a driver gets an I/O request while a suspend is underway. What should it do? Return an error? Block until the suspend is over? Both approaches have their difficulties: Returning an error would mean that suspend is no longer transparent. Even an error like -EAGAIN. Waiting until the suspend is over is likely to be impractical. At a minimum it would involve adding code to drop a lock or mutex, enter the freezer (or its equivalent), and then restart the I/O operation. And then, what if the driver was invoked with O_NONBLOCK? I think it is much better overall to stop I/O requests from being generated at the source, either by freezing userspace or preventing it from making system calls. It's hard to imagine that anybody would miss the small amount of CPU time they'd be giving up by not allowing user threads to run during the time that a suspend is underway! Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
