Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway

Rafael J. Wysocki
2007-07-03T15:15:07Z

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