linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100513220814.GP3428@atomide.com>
Date:	Thu, 13 May 2010 15:08:14 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Paul Walmsley <paul@...an.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	magnus.damm@...il.com, Theodore Ts'o <tytso@....edu>,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>,
	Brian Swetland <swetland@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Garrett <mjg@...hat.com>,
	Benoît Cousson <b-cousson@...com>,
	linux-omap@...r.kernel.org, Vitaly Wool <vitalywool@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

* Alan Stern <stern@...land.harvard.edu> [100513 14:56]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
> 
> > > > And that's why 
> > > > it should be handled by runtime power management instead.
> > > 
> > > Runtime PM is not capable of freezing userspace and shutting down CPUs.  
> > > More or less by definition -- if it could then it wouldn't be "runtime" 
> > > any more, since the processor wouldn't be running.
> > 
> > Not true. We are already powering off CPUs and rebooting them for
> > at least omaps in every idle loop using cpuidle. The memory stays on.
> 
> Okay, that's a valid point.  But is that approach usable in general 
> (i.e., on non-OMAP systems)?

Yes if your system wakes to interrupts at least. If your system does
not wake to timer events, then you'll get missed timers. So it should
work on PC too with CONFIG_NO_HZ and if RTC was used for the timer
wake event.
 
> How do you handle situations where the CPU is currently idle but an 
> event (such as I/O completion) is expected to occur in the near future?  
> You don't want to power-off and reboot then, do you?

The idle code looks at next_timer_interrupt() value, then if the
next timer event if far enough ahead, the system powers down and
wakes to the timer interrupt. It also wakes to device interrupts.

For the drivers to block hitting off-idle custom idle functions
can be used. Paul Walmsley and Kevin Hilman have some ideas on
having generic latency information available for that. So there
are similar issues to opportunistic suspend + suspend blocks
that should be sorted out in a generic way.

For the drivers to power down, some timeout value seems to work
best.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/