On Tue, Apr 17, 2012 at 7:19 PM, Satendra... <satendra.pratap@xxxxxxxxx> wrote:
> Hi Ham,
>
> Thanks for your replies. Below are my thoughts.
>
> On 16 April 2012 19:46, MyungJoo Ham <myungjoo.ham@xxxxxxxxx> wrote:
>>
>> On Mon, Apr 16, 2012 at 7:07 PM, Satendra... <satendra.pratap@xxxxxxxxx>
>> wrote:
>> > Hi Ham,
>> >
>> > I was looking at the simple on demand governor's code and have got few
>> > queries:
>> > - In the code below to check for overflow, why 24 and 7 has been taken?
>> > /* Prevent overflow */
>> > if (stat.busy_time >= (1 << 24) || stat.total_time >= (1 << 24))
>> > {
>> > stat.busy_time >>= 7;
>> > stat.total_time >>= 7;
>> > }
>>
>> It is because 1<<7 >= 100 and 1<<6 < 100. (To get percentage, we are
>> multiplying 100).
>>
> ok. but what about 24? Is it assumed that no one will be allowed to execute
> more than 2^(24-7) units (nsec, msecs etc)?
> Is 2^(24-7) = 128 * 1024 units (nsecs, msecs etc) the default time slice of
> kernel to any code?
It is because we are using 32 bit values and we want to avoid
overflow. If the numbers are sufficiently big, we can forget about the
least bits, which won't impact the precision significantly.
>
>>
>> >
>> > - Also for maximum frequency UINT_MAX is returned which may not be
>> > suited
>> > for some devices.
>>
>> The frequency given to devfreq driver is "recommended frequency", not
>> the "exact frequency required".
>>
>> Thus, the driver is required to choose
>> 1. frequency that is at least (but closest) or same with the
>> "recommended frequency"
>> and if that's impossible,
>> 2. frequency that is closest to the "recommended frequency".
>>
>> Thus, if it's "UINT_MAX", then it should choose the maximum frequency.
>>
>
> You mean we have to check for UINT_MAX in our code and if its so then set
> device at its maximum frequency.
>
>>
>> >
>> > - One more query, whats the unit (usecs, nsecs etc) used for busy and
>> > load
>> > time. Has it got nothing to do with units
>> > and its mere the percentage of busy time?
>>
>> The unit is up to the device driver. It only needs to provide
>> "reasonable" values in u32 to the infrastructure. It could be usec,
>> nsec, #ops, or anything else.
>> I've mentioned it only because jiffy does not seem to be "reasonable";
>> jiffy is too rough. You may even get 0 jiffies for 100 operations
>> while you may get 1 jiffy for 1 operation in the same system.
>>
>> In the governors, maybe busy / total ratio can be used as in
>> simple_ondemand. And you should give values that can support some fair
>> granularity there, which jiffy cannot.
>>
>> >
>> > - If we want to use simple on demand governor then do we need to modify
>> > yours to suit our needs? I mean you have
>> > just provided a framework?
>>
>> If you want to use THE simple_ondemand for your device, you only need
>> to create a devfreq driver. You don't need to modify the governor or
>> the framework/.
>>
>> >
>> > Thanks,
>> > Satendra
>>
>>
>> Cheers!
>> MyungJoo.
>>
>> --
>> MyungJoo Ham, Ph.D.
>> System S/W Lab, S/W Center, Samsung Electronics
>
>
> Thanks,
> Satendra
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
