Date:	Thu, 19 Jan 2012 14:05:20 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	markgross@...gnar.org
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 Wed, Jan 18, 2012 at 12:27 PM, mark gross <markgross@...gnar.org> wrote:
> Either my mail reader is acting up or this email is a bit off topic.  It
> seems to be talking about DVFS/ondemand sampling rates when the
> discussion has been about anding CPU operating frequency constraint
> requests to pm_qos

Yes, indeed. This thread has gone off topic and adjusting sampling
rates has nothing to do with configuring min/max frequencies.

I'll start another thread for adjusting sampling rates for CPUfreq +
Devfreq with PM QoS when a patchset is ready for this.


Thanks.



Cheers!

MyungJoo.

>
> On Tue, Jan 17, 2012 at 07:32:05PM +0900, MyungJoo Ham wrote:
>> On Fri, Jan 13, 2012 at 1:47 PM, mark gross <markgross@...gnar.org> wrote:
>> > On Thu, Jan 12, 2012 at 11:08:44AM +0900, MyungJoo Ham wrote:
>> >>
>> >> 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.
>>
>>
>> - The control knob: polling interval of ondemand-like DVFS mechanisms
>> - It's ok to have no enforcement power. The DVFS mechanism only needs
>> an interface (PM QoS seems fine for this) from user space / device
>> drivers to get the response-time requirement.
>>
>> With some events, we need to adjust DVFS polling interval.
>
> This would be a new type of request.  I don't see it as a pm_qos type of
> data item but, I can see it may be useful.
>
> My first thought is that this should be exported by cpufreq.
>
>> For now, we do this in our devices for user input events (key input,
>> touchscreen input, ...). And some peripheral device drivers want to
>> get "guaranteed response time" depending on their operational modes
>> from memory and bus at the start of their operations.
>>
>> With user input events, user may (doing something heavy) or may not
>> (doing something light) want fast reaction from CPU/MEM/GPU/... in
>> many occasions, and we cannot determine it until the DVFS polling has
>> been done.
>>
>> In average, with near 100% threshold, ondemand-like governors will
>> take 1.5 x polling interval to response. In a system with 100ms
>> polling interval, DVFS mechanism will take usuallly 150ms (and up to
>> 200ms) to react and this is significantly noticable to human users.
>> With 60Hz display system, this is loss of almost 10 frames.
>
> Do you really want to change the sampling rate of the DVFS governors or
> just use a pm_qos request to limit to minimum frequency the governor
> goes for and use a timer to modtime to remove the request on every UI
> event from the touch screen driver interrupt handler?
>
>> In order to address this, a touch event handler (or any
>> thread/callback or anything deals with it) may request QoS with an
>> incoming event to reduce polling interval temporarily.
>>
>> Although PM-QoS does not have the QoS Type for this kind of metric;
>> however, DVFS response time seems to be another QoS metric candidate.
>
> sure its a candidate but I think perhaps an export from cpufreq may be a
> good candidate too.  But, I like my timer scheme best.
>
> However; this still needs a pm_qos class for cpu_min_feq to work.
>
> --mark
>
>>
>>
>> >
>> >> 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?
>>
>> I've not thought about this much yet. I've just seen the need for QoS
>> requirements from GPU people because DVFS mechanism loses a frame or
>> frames often during GPU usage without QoS information.
>>
>> I'm not so familiar with GPUs, so I can't be sure about the metric for
>> graphics throughput. However, could it be "FLOPS", "triangles per
>> second", or GPU clock speed?
>>
>> We have GPU DVFS drivers in linux/drivers/media/video/..., which
>> controls GPU core frequency and measures GPU usage. However, they can
>> be implemented with devfreq framework and move into drivers/devfreq/
>> later.
>>
>>
>>
>> Cheers!
>> MyungJoo.
>>
>>
>> --
>> MyungJoo Ham, Ph.D.
>> Mobile Software Platform Lab, DMC Business, Samsung Electronics
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
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