[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpomEQ__Q4xTaBgHJyE0Meu4au-cXKCAKCqHWTHLRL+R5OA@mail.gmail.com>
Date: Mon, 4 Aug 2014 19:08:51 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Prarit Bhargava <prarit@...hat.com>
Cc: Stephen Boyd <sboyd@...eaurora.org>,
Saravana Kannan <skannan@...eaurora.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lenny Szubowicz <lszubowi@...hat.com>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Robert Schöne <robert.schoene@...dresden.de>
Subject: Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to
be held for duration of changing governors [v2]
On 4 August 2014 17:55, Prarit Bhargava <prarit@...hat.com> wrote:
> The issue is the collision between the setup & teardown of the policy's governor
> sysfs files.
>
> On creation the kernel does:
>
> down_write(&policy->rwsem)
> mutex_lock(kernfs_mutex) <- note this is similar to the "old" sysfs_mutex.
>
> The opposite happens on a governor switch, specifically the existing governor's
> exit, and then we get a lockdep warning.
Okay, probably a bit more clarity is what I was looking for. Suppose we try
to change governor, now tell me what will happen.
> I tried to reproduce with the instructions but was unable to ... ut that was on
> Friday ;) and I'm going to try again this morning. I've also ping'd some of the
> engineers here in the office who are working on ARM to get access to a system to
> do further analysis and testing.
You DON'T need an ARM for that, just try that on any x86 machine which has
multiple groups of CPUs sharing clock line. Or in other terms there are multiple
policy structures there..
You just need to enable the flag we were discussing about, it just decided the
location where governor's directory will get created. Nothing else.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists