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]
Message-ID: <CAJOA=zNQ_fqVXvRdGjwB+GnQZMRzYO-WuLNZh50BMsj4V=ThyQ@mail.gmail.com>
Date:	Wed, 29 Feb 2012 14:19:48 -0800
From:	"Turquette, Mike" <mturquette@...com>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Kevin Hilman <khilman@...com>,
	mark gross <markgross@...gnar.org>, myungjoo.ham@...il.com,
	Jean Pihet <jean.pihet@...oldbits.com>
Subject: Re: [PATCH v2 RESEND] PM / devfreq: add PM QoS support

On Wed, Feb 29, 2012 at 1:43 AM, MyungJoo Ham <myungjoo.ham@...sung.com> wrote:
> +       /* Check the sanity of qos_list/qos_type */
> +       if (profile->qos_type || profile->qos_list) {
> +               switch (profile->qos_type) {
> +               case PM_QOS_CPU_DMA_LATENCY:
> +               case PM_QOS_NETWORK_LATENCY:
> +                       devfreq->qos_use_max = false;
> +                       break;
> +               case PM_QOS_NETWORK_THROUGHPUT:
> +                       devfreq->qos_use_max = true;
> +                       break;

Hello MyungJoo!

I see that you re-using the same old PM QoS handles in this
implementation.  Do you feel this is the right way to do it?  Your
example of using DMA for multimedia devices (given in the changelog)
has nothing to do with network throughput, yet that constraint-type is
used here.

I wonder if a better solution than overloading these classifications exist.

Just to toss around ideas, what about having per-device PM QoS
throughput constraints which are generalized (e.g., not tied to a
concept such as "network").  I've Cc'd Jean Pihet (yet again) who has
some good experience making PM QoS-type interfaces work on a
per-device basis.

I wonder, ultimately, if instead of feeding QoS constraints into
devfreq if a better design might be to have devfreq feed input into a
greater QoS framework.  E.g:

A scalable bus used by many devices might have two different device
drivers that want to call pm_qos_device_tput(...), and also the
devfreq driver for that bus also calls pm_qos_device_tput(...).  So
essentially there are three points in the code where inputs can be
driven into one common per-device QoS layer for the generic concept of
"device throughput".  This way devfreq support is not a prerequisite
for scaling a device in a generic way, but a nice framework for
devices which can monitor their own activity level, built on top of a
per-device pm qos layer.

Thoughts?
Mike
--
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