On 04/29/2013 04:47 PM, Rafael J. Wysocki wrote:
On Monday, April 29, 2013 02:37:28 PM Paul E. McKenney wrote:
On Mon, Apr 29, 2013 at 12:22:32AM +0200, Rafael J. Wysocki wrote:
On Thursday, April 04, 2013 09:57:19 PM Viresh Kumar wrote:
On 4 April 2013 20:23, Nathan Zimmer <nzimmer@xxxxxxx> wrote:
We eventually would like to remove the rwlock cpufreq_driver_lock or convert
it back to a spinlock and protect the read sections with RCU. The first step in
that is moving the cpufreq_driver to use the rcu.
I don't see an easy wasy to protect the cpufreq_cpu_data structure with the
RCU, so I am leaving it with the rwlock for now since under certain configs
__cpufreq_cpu_get is hot spot with 256+ cores.
v5: Go a different way and split up the lock and use the rcu
v6: use bools instead of checking function pointers
covert the cpufreq_data_lock to a rwlock
v7: Rebase to use the already accepted half
v8: Correct have_governor_per_policy
Reviewed location of rcu_read_(un)lock in several spots
Sorry for long delay or too many versions of this patch :)
Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Unfortunately, I had to revert this one, because it is obviously buggy. Why?
Because it adds rcu_read_lock()/rcu_read_unlock() around sysfs_create_file()
which may sleep due to a GFP_KERNEL memory allocation. Sorry for failing to
notice that earlier.
One workaround might be to use SRCU, which allows sleeping in its
critical sections.
Agreed, but at this point of the cycle I'd just preferred to do the revert and
start over.
Thanks,
Rafael
Agreed, I think that would be cleanest. I probably won't have time to
get to it this week though.
Nate
--
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
