Messages in this thread | | | Date | Tue, 29 Apr 2014 12:19:39 +0530 | Subject | Re: [PATCH v2 5/5] cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end | From | Viresh Kumar <> |
| |
On 29 April 2014 11:46, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > Yes, I'm aware that this corner case doesn't work well with my debug
Don't know if its a corner case, it may be the most obvious case for some :)
> patch. I tried to avoid this but couldn't think of any solution.
The problem is not that it wouldn't work for these systems, but we will get WARN_ON() when they shouldn't have come :)
> (One big-hammer way to avoid this is to exclude this infrastructure > for all ASYNC_NOTIFICATION drivers, but I didn't want to go with that > approach, since it makes it look ugly). Do you have any better ideas > to deal with this scenario?
Can't think of anything better than this:
+ WARN_ON(!(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION) && (current == policy->transition_task));
which you already mentioned.
> Also, do we really have cases in mind where a single thread does > multiple frequency transitions in one go? That too in such quick > successions? Echo's to sysfs, changing of governors from userspace etc > all do one frequency transition at a time per-task...
Its not really about if we can think of a real use case or not. The point is, governor is free to call transition calls one after the other (will always happen from a single thread) and it isn't supposed to wait for drivers to finish earlier transitions as ->target() has already returned.
-- viresh
| |