From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750962Ab2ASFFY (ORCPT ); Thu, 19 Jan 2012 00:05:24 -0500 Received: from mail-iy0-f174.google.com ([209.85.210.174]:45294 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717Ab2ASFFV convert rfc822-to-8bit (ORCPT ); Thu, 19 Jan 2012 00:05:21 -0500 MIME-Version: 1.0 In-Reply-To: <20120118032756.GC27153@mgross-G62> References: <1326276130-4042-1-git-send-email-myungjoo.ham@samsung.com> <20120113044757.GB6004@mgross-G62> <20120118032756.GC27153@mgross-G62> Date: Thu, 19 Jan 2012 14:05:20 +0900 Message-ID: Subject: Re: [PATCH 1/2] PM / devfreq: add min/max_freq limit requested by users. From: MyungJoo Ham To: markgross@thegnar.org Cc: "Turquette, Mike" , linux-kernel@vger.kernel.org, Linux PM list , Kyungmin Park , "Rafael J. Wysocki" , Kevin Hilman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2012 at 12:27 PM, mark gross 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 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@vger.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