Re: [PATCH 0/8] Suspend block api (version 8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 29 May 2010, Brian Swetland wrote:

> On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:

> > If no such constraints are active, the QoS-based suspend blocks in an
> > interruptible wait until the number of active QOS_EVENTUALLY
> > constraints drops to 0.  When that happens, it carries out a normal
> > suspend-to-RAM -- except that it checks along the way to make sure that
> > no new QoS constraints are activated while the suspend is in progress.
> > If they are, the PM core backs out and fails the QoS-based suspend.
> >
> > Userspace suspend blockers don't exist at all, as far as the kernel is
> > concerned.  In their place, the Android runs a power-manager program
> > that receives IPC requests from other processes when they need to
> > prevent the system from suspending or allow it to suspend.  The power
> > manager's main loop looks like this:
> >
> >        for (;;) {
> >                while (any IPC requests remain)
> >                        handle them;
> >                if (any processes need to prevent suspend)
> >                        sleep;
> >                else
> >                        write "qos" to /sys/power/state;
> >        }
> 
> The issue with this approach is that if userspace wants to suspend
> while a driver is holding a QOS_EVENTUALLY constraint, it's basically
> going to spin constantly writing "qos" and failing.

No, no.  If userspace wants to suspend while a driver is holding a 
QOS_EVENTUALLY constraint, the user process blocks in an interruptible 
wait state as described in the first paragraph above.

> Could we have write(powerstate_fd, "qos",3) block until all
> QOS_EVENTUALLY constraints are lifted or the system successfully
> suspends and resumes or a signal arrives?

That is basically what I originally wrote.

> > The idea is that receipt of a new IPC request will cause a signal to be
> > sent, interrupting the sleep or the "qos" write.
> 
> Alternatively (to ipc), we could have a driver provide the same
> suspendblock style interface to userspace and maps it to qos
> constraints.  If it's something we maintain out-of-tree, no worries.
> The kernel side api is the bit that's the headache to maintain
> multiple versions of drivers with and without, after all.

Yep.  The idea is that all this userspace-oriented part should be
invisible to the vanilla kernel.

> I'm sure Arve will weigh in on this later, but from what I can see it
> certainly seems like this model provides us with the functionality
> we're looking for, provided the issue with
> spinning-while-waiting-for-drivers-to-release-constraints is sorted
> out.

I'm more concerned about how the other kernel developers will react.

Alan Stern

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux