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
| ||
|
Date: Wed, 26 May 2010 10:42:22 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Arve Hjønnevåg <arve@...roid.com> Cc: "Rafael J. Wysocki" <rjw@...k.pl>, Alan Stern <stern@...land.harvard.edu>, Dmitry Torokhov <dmitry.torokhov@...il.com>, Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>, Kernel development list <linux-kernel@...r.kernel.org>, Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Randy Dunlap <rdunlap@...otime.net>, Andrew Morton <akpm@...ux-foundation.org>, Andi Kleen <ak@...ux.intel.com>, Cornelia Huck <cornelia.huck@...ibm.com>, Tejun Heo <tj@...nel.org>, Jesse Barnes <jbarnes@...tuousgeek.org>, Nigel Cunningham <nigel@...onice.net>, Ming Lei <tom.leiming@...il.com>, Wu Fengguang <fengguang.wu@...el.com>, Maxim Levitsky <maximlevitsky@...il.com>, linux-doc@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>, Greg KH <gregkh@...e.de>, tytso@....edu, James Bottomley <James.Bottomley@...e.de> Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support. On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote: > The biggest problem here is not that it is hard to change our > user-space, but that the proposed change is inferior to what we have > now. It forces us to poll until all drivers stop aborting suspend. On > one hand we have people telling us that all code that polls is broken > and must be fixed (instead of suspending to limit the damage), and on > the other hand we have people suggesting we implement opportunistic > suspend by polling from user-space until suspend succeeds. No it does _not_. You're really not getting that Dmitry is proposing. So your proposal is that when we wake userspace, it opens /dev/suspend_blocker _before_ it consumes whatever event, consumes the event, deals with the event, then closes the suspend_blocker. Then the kernel, upon reaching a 0 suspend_blocker count, will try to suspend again. What Dmitry proposes is that, the app _before_ it consumes the event, pokes at this suspend manager, it increases a blocker count, then consumes the event (the kernel will _not_ auto-suspend), handles it and then again pokes the suspend manager, this time decreasing the blocker count. The suspend manager will, upon reaching a 0 block count, suspend the machine. If that fails, it means there's something to do, an app will inc, work, dec its count, and it will try again once it reaches 0 again. There is no polling what-so-ever in this model. The only thing is that the kernel will not try to auto-suspend and there is no user-space suspend blocker API. -- 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