linux-kernel - Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

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]

Date:	Fri, 7 May 2010 08:54:55 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	Brian Swetland <swetland@...gle.com>,
	Alan Stern <stern@...land.harvard.edu>,
	mark gross <mgross@...ux.intel.com>, markgross@...gnar.org,
	Len Brown <len.brown@...el.com>, linux-doc@...r.kernel.org,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

* Arve Hjønnevåg <arve@...roid.com> [100506 17:05]:
> 2010/5/6 Tony Lindgren <tony@...mide.com>:
> > * Arve Hjønnevåg <arve@...roid.com> [100505 21:11]:

<snip>

> >> This is not a rare event. For example, the matrix keypad driver blocks
> >> suspend when a key is down so it can scan the matrix.
> >
> > Sure, but how many times per day are you suspending?
> >
> 
> How many times we successfully suspend is irrelevant here. If the
> driver blocks suspend the number of suspend attempts depend on your
> poll frequency.

I guess what I'm trying to say is that a failed suspend should be
a rare event.
 
> >> >> With the suspend block model we know the moment we're capable of
> >> >> suspending and then can suspend at that moment.  Continually trying to
> >> >> suspend seems like it'd be inefficient power-wise (we're going to be
> >> >> doing a lot more work as we try to suspend over and over, or we're
> >> >> going to retry after a timeout and spend extra time not suspended).
> >> >>
> >> >> We can often spend minutes (possibly many) at a time preventing
> >> >> suspend when the system is doing work that would be interrupted by a
> >> >> full suspend.
> >> >
> >> > Maybe you a userspace suspend policy manager would do the trick if
> >> > it knows when the screen is blanked and no audio has been played for
> >> > five seconds etc?
> >> >
> >>
> >> If user space has to initiate every suspend attempt, then you are
> >> forcing it to poll whenever a driver needs to block suspend.
> >
> > Hmm I don't follow you. If the userspace policy daemon timer times
> > out, the device suspends. If the device does not suspend because of
> > a blocking driver, then the timers get reset and you try again based
> > on some event such as when the screen blanks.
> >
> 
> This retry is what I call polling. You have to keep retrying until you
> succeed. Also, using the screen blank timeout for this polling is not
> a good idea. You do not want to toggle the screen off and on with with
> every suspend attempt.

The number of retries depends on the power management policy for your
device. And that is often device and use specific.

So having to retry suspend should be a rare event. The userspace should
mostly know when it's OK to suspend.

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/