Re: [PATCH v3] PM / QoS: add pm_qos_update_request_timeout API
From: MyungJoo Ham
Date: Mon Mar 26 2012 - 07:58:13 EST
On Mon, Mar 26, 2012 at 12:02 PM, mark gross <markgross@xxxxxxxxxxx> wrote:
> On Mon, Mar 26, 2012 at 10:41:15AM +0900, MyungJoo Ham wrote:
>> On Sun, Mar 25, 2012 at 1:35 AM, mark gross <markgross@xxxxxxxxxxx> wrote:
>> > I apologize for the lat replay and admit that I was probably wrong to
>> > oppose the idea of time out pm_qos requests. (last week we bumped into
>> > a need for them and now I get it.)
>> > On Wed, Mar 07, 2012 at 02:06:18PM +0900, MyungJoo Ham wrote:
>> >> The new API, pm_qos_update_request_timeout() is to provide a timeout
>> >> with pm_qos_update_request.
>> >> For example, pm_qos_update_request_timeout(req, 100, 1000), means that
>> >> QoS request on req with value 100 will be active for 1000 jiffies.
>> >> After 1000 jiffies, the QoS request thru req is rolled back to the
>> >> request status when pm_qos_update_request_timeout() was called. If there
>> >> were another pm_qos_update_request(req, x) during the 1000 jiffies, this
>> >> new request with value x will override as this is another request on the
>> >> same req handle. A new request on the same req handle will always
>> >> override the previous request whether it is the conventional request or
>> >> it is the new timeout request.
>> >> Signed-off-by: MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx>
>> >> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
>> >> @@ -77,6 +79,8 @@ void pm_qos_add_request(struct pm_qos_request *req, int pm_qos_class,
>> >> s32 value);
>> >> void pm_qos_update_request(struct pm_qos_request *req,
>> >> s32 new_value);
>> >> +void pm_qos_update_request_timeout(struct pm_qos_request *req,
>> >> + s32 new_value, unsigned long timeout_ms);
>> > is ms the right units? could we ever need us?
>> Because jiffies are used for scheduling tasks, I thought ms should be
>> fine and having some devices running fast for some msecs longer won't
>> hurt. However, do you expect scheduling tasks or jiffies may use usecs
>> later? I don't mind using usecs instead of msecs here; thus, I'll
>> update this to use usecs. I'll resend patchset soon.
> I am just asking a question. I'm not sure if us or ms are the better
> units off the top of my head.
For the current structure of Linux (scheduling task, jiffies), I
thought that none of the two is better than the another because the
duration should not be so long and the jiffies are larger than 1 ms.
However, it turns out to be not true: some uses jiffies < 1ms (alpha),
some uses jiffies not cleanly dividable with msecs (omap). Thus, it
appears that usecs is better. Thus, the parameter should be usecs
rather than msecs.
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
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/