linux-kernel - RE: [RFD] Automatic suspend

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:	Mon, 16 Feb 2009 16:36:43 -0600
From:	"Woodruff, Richard" <r-woodruff2@...com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Kyle Moffett <kyle@...fetthome.net>,
	Oliver Neukum <oliver@...kum.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: RE: [RFD] Automatic suspend

> From: Arjan van de Ven [mailto:arjan@...radead.org]
> Sent: Monday, February 16, 2009 3:52 PM
> On Mon, 16 Feb 2009 15:32:06 -0600
> "Woodruff, Richard" <r-woodruff2@...com> wrote:
> >
> > - It provides a way to handle overdrive/turbo operating points out of
> > band from the generically tuned cpufreq governors like ondemand.  The
> > way we characterize overdrive is stricter then what Intel has talked
> > about for x86.
>
> if you have an improved-for-your-systems governor then I'm sure that is
> very welcome in the kernel.

No, the generic governors were not substantially improved. Not every customer is using cpufreq for DVFS. As such we went underneath it. If we had more community presence at the start time we might have also tried that.

> I think just about all of us agree that the final decision needs to be
> in the driver (possibly followed by something that gets various device
> requests and combines it into hw settings); we're just talking about
> what inputs feed into that decision ;)
>
> And for different types of devices that's guaranteed to be different...
> and sometimes we'll be hampered by existing interfaces, so we might end
> up with hacky stuff.

Is there some kind of roadmap which can be plotted which goes from course to more granular control?

Phase 1 (all or nothing): like wakelocks (minus back light): system-auto-suspend-on, system-auto-suspend-off.  The drivers can still veto as they do today.

Phase 2: Subsystem generic tunable, on say latency + bandwidth. Start with CPU then move to classes like USB.

Phase 3: ??? if needed add direct device control, hints on an extended fadvise(), and explicit control left to open/close and direct ioctls?

I don't know that 1,2,3 above even make sense.  However, the notion of actually plotting out a course with goals does as it will take a long time and it is good to get some benefit along the way.

Thanks,
Richard W.

--
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/