linux-kernel - Re: [PATCH 1/2] PM / devfreq: add min/max

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: <20120113044757.GB6004@mgross-G62>
Date:	Thu, 12 Jan 2012 20:47:58 -0800
From:	mark gross <markgross@...gnar.org>
To:	myungjoo.ham@...il.com
Cc:	"Turquette, Mike" <mturquette@...com>,
	linux-kernel@...r.kernel.org,
	Linux PM list <linux-pm@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Kevin Hilman <khilman@...com>
Subject: Re: [PATCH 1/2] PM / devfreq: add min/max_freq limit requested by
 users.

On Thu, Jan 12, 2012 at 11:08:44AM +0900, MyungJoo Ham wrote:
> On Thu, Jan 12, 2012 at 9:20 AM, Turquette, Mike <mturquette@...com> wrote:
> > On Wed, Jan 11, 2012 at 2:02 AM, MyungJoo Ham <myungjoo.ham@...sung.com> wrote:
> >> The frequency requested to devfreq device driver from devfreq governors
> >> is restricted by min_freq and max_freq input.
> >
> > Hello MyungJoo,
> >
> > This change appears to allow userspace to set min/max limits on
> > devfreq devices via sysfs.  Not everyone likes to expose this stuff
> > (similar to the discussions around controlling clocks from debugfs).
> >
> > Should it be wrapped in some new config option?  I think a sane
> > default is that if the sysfs config option for devfreq is selected
> > then it should include all of the read-only stuff.  A second config
> > option (which depends on the option in my previous sentence) should
> > allow the read-write stuff to be enabled separately.  Thoughts?
> >
> > Also, how are you using this feature in practice?  Is this just for
> > test or are you planning on more fine-grained control of device
> > frequencies from userspace?
> >
> > Mike
> 
> Hello Mike,
> 
> 
> Although turning off clocks inconsiderately usually crashes the
> system, setting min/max frequencies generally affects (if not always)
> only the performance and power consumption.
> 
> For the optional min/max freq, I think each device should be able to
> choose to use it or not. Thus, rather than adding a Kconfig option,
> I'll let "profile" (struct devfreq_dev_profile) include
> "expose_user_min_max_freq" option.
> 
> In practice, we have been using min/max to test DVFS behaviors and its
> side effects. And we are going to use them to 1. restrict power
> consumption forcibly by the platform software if it is too hot or the
> battery is low, and to 2. guarantee the minimum performance for
> specific tasks controlled by the platform software.
> 
> Anyway, the reason 2 could be tackled by pm-qos if we allow more
> options in pm-qos with 1. pm qos type to enforce DVFS response time.
what would pm_qos do with DVFS response time?  What power management
knob would it enable a constraint for?

pm_qos doesn't do anything but enable power throttling code to consider
a constraint on how far to throttle "something".  pm_qos has no
enforcement power.

> 2. pm qos type to enforce graphics performance. And adding a duration
> option to pm-qos requests will be helpful (sort of a helper function):
> i.e., pm_qos_timed_request(struct pm_qos_request *req, int
> pm_qos_class, s32 value, unsigned long duration_ms);

What would be good units for graphics throughput?
Where in the graphics driver would you insert the equivalent of cpufreq?
to control the GPU core frequency?

--mark

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