lkml.org 
[lkml]   [2007]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
    Rafael J. Wysocki writes:

    > They are mostly related to kernel threads, that we've already agreed no to
    > freeze (except for the ones that want that, but they will be responsible for
    > getting everything right). The initial patches for that are in -mm and more
    > will come.

    Serious question: which kernel threads would actually want to be
    frozen?

    Threads that do no I/O at all don't care about suspend/resume and
    don't need to be frozen in any case. Threads that issue I/O requests
    in order to service incoming I/O requests can't be frozen because of
    the possibility of deadlock. Which leaves threads that do I/O just
    for the fun of it. :)

    What am I missing?

    > > Also, no-one has yet answered my fundamental objection to the freezer,
    > > which is that the very kernel threads we would want to freeze are
    > > often the same ones that we must not freeze, namely the threads that
    > > issue I/O requests in order to satisfy incoming I/O requests.
    >
    > See above. We're moving away from freezing kernel threads.

    I believe the distinction between threads and user processes is a
    false one, because user processes can now do things that were formerly
    only doable by kernel threads.

    > > If there was an automatic way to construct the graph of dependencies
    > > (including data flows) between tasks, and derive an ordering for
    > > freezing that guarantees that all I/Os will get completed without
    > > deadlocks, then I could accept the freezer. But we don't have
    > > anything like that.
    >
    > No we don't.
    >
    > Still, my position is this:
    >
    > 1) The freezer (in the modified form, with the freezing of kernel threads
    > limited to the ones that want to be frozen) is needed for hibernation.
    >
    > 2) The freezer is generally not needed for suspend, _but_ there are drivers
    > in the tree that rely on it being used. Thus, at some point in time we can

    Do you know which drivers they are? I'm happy to help hack things
    into shape.

    > remove the freezer from the suspend code path, _but_ no sooner than we are
    > sure that the majority of drivers is prepared for that.
    >
    > 3) In the meantime, if there are freezer-related problems, they should be
    > fixed rather than used as arguments for immediate removal of it, because of 2).

    I don't know how you can make the freezer completely deadlock-free
    while still providing the guarantee that some drivers currently need,
    without constructing the dependency graph I mentioned.

    Paul.
    -
    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-07-04 13:39    [W:4.128 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site