Hi! > > > 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. Yes. > 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. ... > 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. I like freezer better :-). > 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. No, -EAGAIN is not nice. > 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? Blocking would be possible option. I agree it is tricky to implement... it may also be useful for a harddrive: "I'm riding a horse at 40kph now, so you'll kill the harddrive if you access it; just freeze everyone until we are at the other end of meadow". ...hmm, but this seems to be blockdevice specific, and I can't think of a network or char driver where similar behaviour would be useful. > 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! Agreed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
