lkml.org 
[lkml]   [2007]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
    Date
    On Tuesday, 3 July 2007 16:59, Johannes Berg wrote:
    > On Tue, 2007-07-03 at 10:50 -0400, Alan Stern wrote:
    >
    > > Time for me to jump in.
    >
    > :)
    >
    > > USB already implements runtime PM. If a device is suspended at runtime
    > > and a task tries to access it, the device is automatically resumed.
    > > No problem there.
    >
    > Right.
    >
    > > The problem comes when the system is doing a STR. Right now the code
    > > doesn't keep track of the difference between a runtime suspend and a
    > > system suspend -- once the device is suspended, it's suspended, period.
    > > Consequently, a non-frozen user task trying to do I/O to a suspended
    > > device during STR will cause that device to resume, thereby forcing the
    > > system suspend to abort. Something much like this has actually
    > > happened and been reported as a bug on LKML (I don't have a URL handy,
    > > and it was actually a non-frozen kernel thread interfering with
    > > hibernate rather than a non-frozen user task interfering with STR, but
    > > the principle is the same).
    >
    > Yeah, I can see that happen.
    >
    > > Yes, the code could be changed to keep track of the reason for a device
    > > suspend. But that just raises the old problem of what to do when
    > > there's an I/O request for a suspended device during STR.
    > >
    > > > I think the core of the discussion isn't appreciated by everybody here
    > > > yet---we need to solve both run-time and suspend-to-ram-time device
    > > > suspend, not just one of them.
    > >
    > > Runtime suspend isn't a problem. Only STR.
    >
    > Ah but for all those character devices people were saying are the
    > problem we haven't even solved runtime suspend as far as I can tell from
    > the discussion.
    >
    > > Consider a particularly troublesome case: During STR, a non-frozen task
    > > writes to /sys/bus/BBB/drivers/DDD/bind. The sysfs core grabs the
    > > device semaphore and calls the driver's probe routine. If the driver
    > > isn't PM-aware it simply tries to initialize the device and fails
    > > because the device is already suspended. That's no good; it isn't
    > > transparent.
    > >
    > > So assume the driver is PM-aware. It tries to resume the device, which
    > > fails because STR is underway. Now what can it do? There's only one
    > > possibility: It must block until the resume call can succeed. But when
    > > is that?
    > >
    > > It has to be before the PM core tries to resume the device, because the
    > > core will try to acquire the device semaphore and will block waiting
    > > for the probe call to complete. But it has to be after the PM core
    > > resumes the device's parent, because obviously the device can't resume
    > > until its parent is awake.
    > >
    > > As you can see, this is a very difficult problem to solve.
    >
    > Indeed. Actually, one could argue that it's impossible to solve the
    > problem as long as we try to call out to userspace during suspend and
    > need to wait until that's finished, like in the case of sys_sync() and
    > fuse filesystems, and probably other cases. Maybe we should make *those*
    > calls return a failure so that the suspend isn't transparent inside the
    > kernel but is transparent to userspace.

    Well, it generally needs more consideration. :-)

    I think that we should introduce mechanisms that will allow us to notify all
    kernel subsystems, including FUSE and similar, that the system is going to
    enter a sleep state (one of those is the notifier chain introduced recently).

    Then, they may react to such a notification by entering a "suspend" mode
    of operation in which they will return errors from some callbacks that
    otherwise should have succeeded etc. That depends on the subsystem in
    question.

    Greetings,
    Rafael


    --
    "Premature optimization is the root of all evil." - Donald Knuth
    -
    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-03 17:17    [W:0.025 / U:0.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site