lkml.org 
[lkml]   [2015]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer
    On Fri, 30 Oct 2015, Jiri Kosina wrote:

    > This series is a followup to my proposal I brought up on Kernel Summit in
    > Seoul. Noone seemed to had any principal objections, so let's have wider
    > audience look into it.
    >
    > In a nuthsell: freezing of kernel threads is horrible interface with
    > unclear semantics and guarantees, and I am surprised it ever worked
    > properly. Plus there are a lot of places that simply use it in a
    > completely wrong way (which is not suprising, given the lack of defined
    > semantics and requirements).
    >
    > I've tested this over a series of suspend/resume cycles on several
    > machines with at least ext4, btrfs and xfs, and it survived the testing
    > without any harm.
    >
    > Patch 1/3 implements the actual change, and has a more detailed
    > explanation on "why?" and "how?" questions in the changelog

    This patch talks about freezing in relation to hibernation. What about
    other forms of suspend?

    Also, it replaces kthread freezing with filesystem freezing. What
    about kthreads performing I/O that doesn't go through a filesystem?
    You write:

    > the only facility that is needed during suspend: "no persistent fs
    > changes are allowed from now on"

    I would say instead "no I/O is allowed from now on". Maybe that's an
    overstatement, but I think it comes closer to the truth.

    > Patch 2/3 nukes all (hopefully) the calls to freezer from kthreads
    > in Linus' tree (as of 858e904bd71)
    >
    > Patch 3/3 introduces WARN_ON() if anyone is trying to make use of
    > this again
    >
    > Open questions / discussion points:
    >
    > - is the way I am traversing list of superblocks backwards enough to
    > guarantee correct ordering? Especially: does this work as intended for
    > FUSE?
    >
    > - should freezable workqueues be dealt with the same way? I haven't even
    > started to look into them in a serious way, but it seems like the
    > drivers that are making use of them would actually like to use proper
    > PM callbacks instead

    In the examples of freezable workqueues that I'm familiar with, what we
    really want is for the queue to stop running before the system goes any
    further into suspend. This could be implemented with PM callbacks, but
    using the freezer instead seems a lot simpler.

    Alan Stern



    \
     
     \ /
      Last update: 2015-10-30 17:01    [W:2.580 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site