Re: Runtime PM discussion notes

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

 



On Fri, 24 Jun 2011, Paul Walmsley wrote:

> > > 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?

I'm not thinking of anything in particular.  Just brainstorming...

If somebody decides to freeze userspace without putting the entire 
system to sleep, how will they know when to unfreeze?  A certain amount 
of specialized kernel/userspace interaction would be needed.

> > > 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.

Then those two are almost the same thing.  It doesn't seem to make much 
sense to say "I want to stop these processes from running now, but 
allow them to run if one of them gets a timer or I/O signal".

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

Once userspace is inactive, the kernel probably doesn't have very much
to do.  Responding to some network packets, maybe, if the network
interfaces are left running (like a router but without support for
dynamic routing protocols).  In general, I don't think a system could
do a whole lot of useful work in such a state.

> > > 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.

This is more of a "transition" issue than a "steady-state" concern.  
When userspace is frozen, it can't generate new I/O requests.  If the 
old ones were left to terminate normally, pretty soon the I/O queues 
would drain by themselves.

In short, I'm not sure how these ideas would yield anything new and 
worthwhile.  Maybe I'm just slow today...

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