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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 3 May 2010 21:41:51 -0700
From:	mark gross <640e9920@...il.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	mgross@...ux.intel.com, davidb@...cinc.com, dwalker@...eaurora.org,
	bruce.w.allan@...el.com, lkml <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, mcgrof@...il.com,
	linux-pm <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH]PM QOS refresh against next-20100430

On Mon, May 03, 2010 at 10:33:00AM -0600, Jonathan Corbet wrote:
> On Fri, 30 Apr 2010 14:20:43 -0700
> mark gross <mgross@...ux.intel.com> wrote:
> 
> > This patch changes the string based list management to a handle base
> > implementation to help with the hot path use of pm-qos
> 
> Having taken a quick look, I think the API change makes a lot of
> sense.  Hot paths are one thing; avoidance of accidental conflicts
> would be another.

Conflicts? say more please.
 
> One question, though...  one clear use of this API is for drivers to
> say "don't go into C3 or deeper because things go wrong"; I'm about to
> add another one of those.  It works, but the use of a
> PM_QOS_CPU_DMA_LATENCY requirement with a hard-coded number that one
> hopes is small enough seems a bit...indirect.  I wonder if it would be
> clearer and more robust to add a new requirement^Wrequest type saying
> "the quality of service I need is shallow sleeps only"?

Well, adding such an api to cpuidle could do this for you.  "shallow" is
hard to define, but one could do what google did and define a
cpu_wake_lock type of API to block entry into any low power halt/mwait
type of state.  i.e. shallow would be C0, or just halt in idle.

If such a thing fits a "hotpath" API extention to pm_qos basically
implementing a low overhead disable lowpower behavior without having to
walk the pm_qos lists to get an agrigate value.  But, if such an api
belongs in cpu_idle thats fine too, as the only user of such and API
really is devices (like spi devices hangining of a clock that goes down
in the deeper idle states) wanting to block low power idle states, so be
it.

--mgross

> 
> jon
> _______________________________________________
> linux-pm mailing list
> linux-pm@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ