lkml.org 
[lkml]   [2007]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
    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

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

    \
     
     \ /
      Last update: 2007-06-05 20:49    [W:3.004 / U:0.384 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site