Re: [PATCH 1/2] PM / devfreq: add min/max_freq limit requested byusers.

[mark gross]

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

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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/