2013/8/14 Viresh Kumar <viresh.kumar@xxxxxxxxxx>:
> I am still not sure if I got what you are trying to say, sorry :(
>
> On 14 August 2013 13:06, Xiaoguang Chen <chenxg.marvell@xxxxxxxxx> wrote:
>> Please see below code in __cpufreq_governor function
>>
>> mutex_lock(&cpufreq_governor_lock);
>> if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
>> //////////// <1> Here one process A tries
>> to stop governor, it finds governor is enabled, so it will pass down.
>> (policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
>> /////////////<3> Process B tries to start
>> governor, it finds enable flag is false, so it can also pass down.
>
> Processes aren't allowed to call START/STOP in random manner. They
> must do a STOP first, if it succeeds do a START.
>
> So lets see it this way:
>
> Process A Process B
> STOP
> STOP
> START (If STOP passed)
> START (If STOP passed)
>
> So, Process B tries to STOP/START after governor is Stopped by A.
> Now call to STOP for process B will fail as we are already stopped..
>
> Can you explain with this example the problem you are trying to solve?
Yes, "START (If STOP passed)", this is important, we don't have this
patch on our code base, So even Process B's STOP failed(as governor
enable flag is set to false by process A already ), it can still do
START operation, So my problem occurs.
My problem is that I see ondemand governor is started twice during
frequent governor switch and cpu hotplug stress test.
The After seeing your patch for the return value checking, I think my
problem should not occur.
This issue really botherred me for a long time. :(
Thanks
Xiaoguang
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
