[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Jun 2010 12:57:10 +0200
From: Vitaly Wool <vitalywool@...il.com>
To: Florian Mickler <florian@...kler.org>
Cc: david@...g.hm, Brian Swetland <swetland@...gle.com>,
Arve Hjønnevåg <arve@...roid.com>,
Arjan van de Ven <arjan@...radead.org>, tytso@....edu,
Peter Zijlstra <peterz@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
James Bottomley <James.Bottomley@...e.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration
2010/6/6 Florian Mickler <florian@...kler.org>:
> Suspend_blockers allow the system to suspend ("mem">/sys/power/state
> suspend), when the userspace decides that the device is not in use.
Sorry. What? Blockers allow the system to suspend?
> So implementing suspend_blockers support does not impact any
> optimizations done to either system A nor system B.
Suspend blockers by themselves are of no use. Completely. So any talks
on suspend blockers separated from the sleep policy are completely
pointless.
The suspend blockers are of use when the userspace tries to blindly
freeze the tasks to enter the suspend state. This way of hammering the
system down obviously impacts everything.
~Vitaly
--
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/
Powered by blists - more mailing lists