On Mon, 4 Jun 2007, Pavel Machek wrote: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 -
| Heiko Carstens | [patch -mm] s390: struct bin_attribute changes |
| Andrew Morton | 2.6.25-rc2-mm1 |
| Eric W. Biederman | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Andrew Morton | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes |
