Re: Runtime PM discussion notes

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

 



Hi Alan,

On Thu, 23 Jun 2011, Alan Stern wrote:

> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > 
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
>
> At the moment, isn't it possible for the userspace ioctl PM interface to 
> freeze processes without going all the way through to a system sleep?

Something like cgroup_freezer is probably more useful, since it can freeze 
a configurable subset of processes.  Consider the common mobile use-case 
of audio playback while the display, touchscreen, etc. are disabled.  
In such a case, large portions of userspace can be frozen or paused, but 
not all.

> > But suspend users don't know this either, since they can't predict when 
> > the next external wakeup can happen.
> 
> But they do know (or should know) that they don't intend to use the 
> system in the near future.  It might be good to have a separate way to 
> express that idea to the kernel.

Are you thinking of the current userspace interfaces to suspend, or 
something else?

> > > and (2) that it is supposed to ignore wakeup signals from certain
> > > sources. 
> > 
> > Isn't this configurable now without system suspend with the wakeup sources 
> > code?
> 
> The wakeup code does two things: It tells the system which devices 
> should be enabled for wakeup when the system sleeps (as opposed to 
> cpuidle, when all devices should be able to generate interrupts),

Perhaps the same interface would be useful for CPUIdle-based approaches.

> > The individual components of system suspend are definitely useful:
> > 
> > 1. preventing userspace processes from keeping the system from entering 
> >    idle
> > 2. preventing userspace processes from waking the system back up
> 
> It's not clear what this means.  How can a user process wake the system 
> up?  Are you referring to user timers?

Yes.

> > 3. preventing kernel code from keeping the system from entering idle
> 
> Relatively few kernel threads are freezable.  The ones that are tend to 
> be involved in device management.  Did you have something specific in 
> mind?

No, nothing specific.

> > 4. preventing kernel code from waking the system back up
> > 5. requesting that drivers abort what they are currently doing
> 
> Not exactly "abort".  More like "stop processing their I/O queues".

Yes, that's a better way of putting it; hopefully most drivers are doing 
that.


- Paul
_______________________________________________
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