login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2010
»
May
»
27
Re: [PATCH 1/8] PM: Opportunistic suspend support.
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From: Arve Hjønnevåg
Subject:
Re: [PATCH 1/8] PM: Opportunistic suspend support.
Date: Thursday, May 27, 2010 - 4:52 pm
2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
quoted text
> On Thu, May 27, 2010 at 04:36:28PM -0700, Arve Hjønnevåg wrote: >> 2010/5/27 Dmitry Torokhov <dmitry.torokhov@gmail.com>: >> > On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hjønnevåg wrote: >> >> 2010/5/26 Alan Stern <stern@rowland.harvard.edu>: >> >> > On Wed, 26 May 2010, Arve Hjønnevåg wrote: >> >> > >> >> >> > I must be missing something. In Arve's patch 1/8, if the system is in >> >> >> > opportunistic suspend, and a wakeup event occurs but no suspend >> >> >> > blockers get enabled by the handler, what causes the system to go back >> >> >> > into suspend after the event is handled? Isn't that a loop of some >> >> >> > sort? >> >> >> > >> >> >> >> >> >> Yes it is a loop. I think what you are missing is that it only loops >> >> >> repeatedly if the driver that aborts suspend does not use a suspend >> >> >> blocker. >> >> > >> >> > You mean "the driver that handles the wakeup event". I was asking what >> >> > happened if suspend succeeded and then a wakeup occurred. But yes, if >> >> > a suspend blocker is used then its release causes another suspend >> >> > attempt, with no looping. >> >> > >> >> >> > And even if it isn't, so what? What's wrong with looping behavior? >> >> >> >> >> >> It is a significant power drain. >> >> > >> >> > Not in the situation I was discussing. >> >> > >> >> >> >> If you meant it spend most of the time suspended, then I agree. It >> >> only wastes power when a driver blocks suspend by returning an error >> >> from its suspend hook and we are forced to loop doing no useful work. >> >> >> > >> > If driver refuses to suspend that means there are events that need >> > processing. I fail to see why it would be called "looping doing no >> > useful work". >> >> Because the useful work is done in another thread. All the loop does >> is check if the useful work has completed which most likely will slow >> down the useful work. > > Or useful work could signal when it is done processing critical section. >
That is what suspend_unblock does.
quoted text
>> Blocking suspend with a suspend blocker until >> the useful work is done is more efficient. >> > > -- > Dmitry >
-- Arve Hjønnevåg --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Alan Stern
, (Wed May 26, 5:47 pm)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Arve Hjønnevåg
, (Wed May 26, 5:52 pm)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Dmitry Torokhov
, (Thu May 27, 11:13 am)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Rafael J. Wysocki
, (Thu May 27, 1:00 pm)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Arve Hjønnevåg
, (Thu May 27, 4:36 pm)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Dmitry Torokhov
, (Thu May 27, 4:48 pm)
Re: [PATCH 1/8] PM: Opportunistic suspend support.
, Arve Hjønnevåg
, (Thu May 27, 4:52 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Michael Trimarchi
Re: [PATCH] VFS: make file->f_pos access atomic on 32bit arch
Miklos Szeredi
[patch 14/15] vfs: more path_permission() conversions
Serge E. Hallyn
Re: [RFC v5][PATCH 7/8] Infrastructure for shared objects
Bernd Schmidt
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Takashi Iwai
[PATCH 2/2] input: Add LED support to Synaptics device
git
:
Junio C Hamano
Re: mingw, windows, crlf/lf, and git
Eyvind Bernhardsen
Re: Where has "git ls-remote" reference pattern matching gone?
Shawn O. Pearce
Re: Switching from CVS to GIT
Todd Zullinger
Re: [PATCH 2/2] send-email: rfc2047-quote subject lines with non-ascii characters
Santi Béjar
Re: How to use git-fmt-merge-msg?
linux-netdev
:
Ramkrishna Vepa
[net-2.6 PATCH 1/10] Neterion: New driver: Driver help file
Mark Anthony
invitation / inquiry
Ingo Molnar
Re: [PATCH 08/16] dma-debug: add core checking functions
David Miller
Re: [PATCH 1/3] f_phonet: dev_kfree_skb instead of dev_kfree_skb_any in TX callback
Sascha Hauer
[PATCH 03/12] fec: do not typedef struct types
git-commits-head
:
Linux Kernel Mailing List
amba: struct device - replace bus_id with dev_name(), dev_set_name()
Linux Kernel Mailing List
MIPS: Yosemite: Convert SMP startup lock to arch spinlock.
Linux Kernel Mailing List
ARM: S5PC100: IRQ and timer
Linux Kernel Mailing List
davinci: edma: clear interrupt status for interrupt enabled channels only
Linux Kernel Mailing List
x86, mm, kprobes: fault.c, simplify notify_page_fault()
openbsd-misc
:
Daniel A. Ramaley
Re: [semi-OT] Can anyone recommend an OpenBSD-compatible colour laser printer?
Matthias Kilian
Re: can't get vesa @ 1280x800 or nv
Tobias Ulmer
Re: Problem after upgrade 4.5 to 4.6: ERR M
Philip Guenther
Re: SIGCHLD and libpthread.so
J.C. Roberts
Re: [semi-OT] Can anyone recommend an OpenBSD-compatible colour laser printer?
Colocation donated by:
Syndicate