Re: Attempted summary of suspend-blockers LKML thread

[Paul E. McKenney]

On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@xxxxxxx wrote:
> > On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> 
> Guys, please try to cut unneeded text from the quotes - it makes it much
> easier to find the new text.
> 
> >>> Well, not really from the Linux point of view.  It's not massively
> >>> different to something like keeping an ethernet controller sufficiently
> >>> alive to allow it to provide wake on LAN functionality while the system
> 
> >> The wake-on-LAN and the lights-out management systems are indeed
> >> interesting examples, and actually pretty good ones.  The reason I
> >> excluded them is that they don't do any application processing -- their
> >> only purpose is the care and feeding of the system itself.  In contrast,
> >> the embedded processors are able to do significant applications processing
> >> (e.g., play back music) while any CPUs are completely shut down and most
> >> of the memory is powered down as well.
> 
> This isn't a particularly meaningful distinction, things like the LoM
> systems on servers are generally at least as capable as things like the
> DSPs doing tasks like offloaded MP3 decode and often provide useful
> services in themselves (like system monitoring).  It's really just
> semantics to treat them differently to something like a cellular modem -
> at a high level they're both just independant processors ticking away
> without the application processor.

I agree that a smartphone's cellular modem can be argued to be very
similar to wake-on-LAN.  The smartphone applications that seem to me
to be very different from wake-on-LAN are things like audio playback,
where the system is providing service to the user during the time that
it is suspended.

> > one other significant issue is that on the PC, things like wake-on-LAN,  
> > lights out management cards, etc require nothing from the main system  
> > other than power. If they do something, they are sending the signal to 
> > the chipset, which then wakes the system up. they don't interact with the 
> > main processor/memory/etc at all.
> 
> I don't see that it makes much difference what gets kept alive - at the
> end of the day the point is that we're making a decision to keep bits of
> the system alive over suspend.

The distinction is whether or not the system is perceived to be actively
doing something useful while it is suspended.  Yes, this is subjective,
but the distinction is still important.

> > So as I see it, we need to do one of two things.
> 
> > 1. change the suspend definition to allow for some things to not be  
> > suspended
> 
> This is essentially what's already happening.

The time-of-day clock is certainly a case in point here.  ;-)

							Thanx, Paul

> > 2. change the sleep/low-power mode definition to have a more standardized 
> > way of turning things off, and extend it to allow clocks to be turned off 
> > as well (today we have things able to be turned off, drive spin-down for  
> > example, but per comments in this thread it's all one-off methods)
> 
> Currently things like clock trees are frequently managed orthogonaly to
> the system power state to at least some extent anyway - for example,
> perfectly normal wake events like button presses will often require
> clocks for things like debouncing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/