On 10/13/2014 06:43 AM, Viresh Kumar wrote:
> On 1 August 2014 22:48, Stephen Boyd wrote:
>> On 08/01/14 03:27, Prarit Bhargava wrote:
>>>
>>> Can you send me the test and the trace of the deadlock? I'm not creating
>>> it with:
>>>
>>
>> This was with conservative as the default, and switchin
On 1 August 2014 22:48, Stephen Boyd wrote:
> On 08/01/14 03:27, Prarit Bhargava wrote:
>>
>> Can you send me the test and the trace of the deadlock? I'm not creating it
>> with:
>>
>
> This was with conservative as the default, and switching to ondemand
>
> # cd /sys/devices/system/cpu/cpu2/cpu
On 08/13/2014 12:57 PM, Prarit Bhargava wrote:
On 08/05/2014 06:51 PM, Saravana Kannan wrote:
I definitely have a fix for this and the original race you reported. It's
basically reverting that commit you reverted + a fix for the deadlock. That's
the only way to fix the scaling_governor issue
On 13 August 2014 15:28, Prarit Bhargava wrote:
> Anywhere from 2-4 sockets, 8 - 240 cpus (depending on # of sockets), x86 arch.
That's what. We know that it does happen on multi cluster systems
and I was reproducing it on a single cluster one. i.e. all CPUs share
clock line.
--
To unsubscribe fr
On 08/05/2014 06:51 PM, Saravana Kannan wrote:
>
> I definitely have a fix for this and the original race you reported. It's
> basically reverting that commit you reverted + a fix for the deadlock. That's
> the only way to fix the scaling_governor issue.
>
> You fix the deadlock by moving the
On 08/13/2014 03:39 AM, Viresh Kumar wrote:
> On 12 August 2014 17:03, Prarit Bhargava wrote:
>> Okay, this is what I have and I can reproduce this *easily* 100% of the time.
>>
>> I've used your above config options and have enabled LOCKDEP.
>>
>> In order to restore the locking, I've applied t
On 12 August 2014 17:03, Prarit Bhargava wrote:
> Okay, this is what I have and I can reproduce this *easily* 100% of the time.
>
> I've used your above config options and have enabled LOCKDEP.
>
> In order to restore the locking, I've applied the following patch to the
> cpufreq
> core (sorry fo
On 08/12/2014 05:03 AM, Viresh Kumar wrote:
> On 7 August 2014 15:45, Viresh Kumar wrote:
>> On 7 August 2014 15:42, Prarit Bhargava wrote:
>>> That should have done it. What are your CPUFREQ configs?
>>
>> You can check the same .config I attached last time for that :)
>>
>> CONFIG_CPU_FREQ=y
On 7 August 2014 15:45, Viresh Kumar wrote:
> On 7 August 2014 15:42, Prarit Bhargava wrote:
>> That should have done it. What are your CPUFREQ configs?
>
> You can check the same .config I attached last time for that :)
>
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_STAT
On 7 August 2014 15:42, Prarit Bhargava wrote:
> That should have done it. What are your CPUFREQ configs?
You can check the same .config I attached last time for that :)
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAUL
On 08/07/2014 02:36 AM, Viresh Kumar wrote:
> On 6 August 2014 20:38, Stephen Boyd wrote:
>> On 08/06, Prarit Bhargava wrote:
>>> Are you sure you're not seeing another lockdep warning? That was my
>>> problem --
>>> there was an xfs related lockdep warning which then resulted in lockdep
>>>
On 6 August 2014 20:38, Stephen Boyd wrote:
> On 08/06, Prarit Bhargava wrote:
> > Are you sure you're not seeing another lockdep warning? That was my
> > problem --
> > there was an xfs related lockdep warning which then resulted in lockdep
> > being
> > disabled from that point on.
There is
On 08/06, Prarit Bhargava wrote:
>
>
> On 08/06/2014 04:10 AM, Viresh Kumar wrote:
> > On 6 August 2014 03:36, Saravana Kannan wrote:
> >> Stephen and I looked into this. This is not a sysfs framework difference.
> >> The reason we don't have this issue when we use global tunables is because
> >
On 08/06/2014 04:10 AM, Viresh Kumar wrote:
> On 6 August 2014 03:36, Saravana Kannan wrote:
>> Stephen and I looked into this. This is not a sysfs framework difference.
>> The reason we don't have this issue when we use global tunables is because
>> we add the attribute group to the cpufreq_glo
On 6 August 2014 03:36, Saravana Kannan wrote:
> Stephen and I looked into this. This is not a sysfs framework difference.
> The reason we don't have this issue when we use global tunables is because
> we add the attribute group to the cpufreq_global_kobject and that kobject
> doesn't have a kobj_
On 08/05/2014 03:42 PM, Prarit Bhargava wrote:
So back to the original problem, which in short, revolves around these two
functions (with comments included by me):
/* called with kernfs rwsem for this kobj held */
static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
{
So back to the original problem, which in short, revolves around these two
functions (with comments included by me):
/* called with kernfs rwsem for this kobj held */
static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
{
struct cpufreq_policy *policy = to_policy(ko
On 08/05/2014 03:20 PM, Prarit Bhargava wrote:
On 08/05/2014 06:06 PM, Saravana Kannan wrote:
On 08/05/2014 03:53 AM, Viresh Kumar wrote:
On 5 August 2014 16:17, Prarit Bhargava wrote:
Nope, not a stupid question. After reproducing (finally!) yesterday I've been
wondering the same thing.
On 08/05/2014 06:06 PM, Saravana Kannan wrote:
> On 08/05/2014 03:53 AM, Viresh Kumar wrote:
>> On 5 August 2014 16:17, Prarit Bhargava wrote:
>>> Nope, not a stupid question. After reproducing (finally!) yesterday I've
>>> been
>>> wondering the same thing.
>>
>> Good to know that :)
>>
>>> I
On 08/05/2014 03:53 AM, Viresh Kumar wrote:
On 5 August 2014 16:17, Prarit Bhargava wrote:
Nope, not a stupid question. After reproducing (finally!) yesterday I've been
wondering the same thing.
Good to know that :)
I've been looking into *exactly* this. On any platform where
cpu_weight(a
On 5 August 2014 16:17, Prarit Bhargava wrote:
> Nope, not a stupid question. After reproducing (finally!) yesterday I've been
> wondering the same thing.
Good to know that :)
> I've been looking into *exactly* this. On any platform where
> cpu_weight(affected_cpus) == 1 for a particular cpu t
On 08/05/2014 03:46 AM, Viresh Kumar wrote:
> On 2 August 2014 01:06, Stephen Boyd wrote:
>> I have the same options. The difference is that my driver has a governor
>> per policy. That's set with the CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag.
>
> You may call me stupid but I got a bit confused aft
On 2 August 2014 01:06, Stephen Boyd wrote:
> I have the same options. The difference is that my driver has a governor
> per policy. That's set with the CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag.
You may call me stupid but I got a bit confused after looking into the code
again. Why does the crash dum
On 5 August 2014 11:59, wrote:
> Looks like Srivatsa has gone off the grid too. I'm hoping at least one of
> you can do a review of my series. Come on guys, not everyone has to work
> on the same patch/issue. :-(
Srivatsa is currently going through some personal stuff. He is joining MIT
for his
Viresh Kumar wrote:
> On 5 August 2014 01:46, Saravana Kannan wrote:
>> The problem is when between one thread trying to cat a governor's file
>> (say,
>> sampling_rate) vs the governor getting a POLICY_EXIT.
>
> I don't see two threads racing against each other here. Simply changing
> the govern
On 5 August 2014 01:46, Saravana Kannan wrote:
> The problem is when between one thread trying to cat a governor's file (say,
> sampling_rate) vs the governor getting a POLICY_EXIT.
I don't see two threads racing against each other here. Simply changing
the governor from conservative->ondemand cr
On 08/04/2014 06:38 AM, Viresh Kumar wrote:
On 4 August 2014 17:55, Prarit Bhargava 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
On 08/04/2014 10:00 AM, Prarit Bhargava wrote:
> There is an already reported LOCKDEP warning in the xfs code that fires at
> login
> so I know LOCKDEP is functional.
>
It turns out that the above was the problem. I didn't realize that LOCKDEP will
only report a single warning :(
[Aside: Is
On 08/04/2014 09:38 AM, Viresh Kumar wrote:
> On 4 August 2014 17:55, Prarit Bhargava 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) <-
On 4 August 2014 17:55, Prarit Bhargava 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 o
On 08/04/2014 06:36 AM, Viresh Kumar wrote:
> Sorry for the delay guys, was away :(
>
>>
>> Possible unsafe locking scenario:
>>
>> CPU0CPU1
>>
>>lock(&policy->rwsem);
>> lock(s_active#9);
>>
Sorry for the delay guys, was away :(
Adding Robert as well, he reported something similar so better discuss here.
On 1 August 2014 22:48, Stephen Boyd wrote:
> This was with conservative as the default, and switching to ondemand
>
> # cd /sys/devices/system/cpu/cpu2/cpufreq
> # ls
> affected_cp
On 08/01/2014 05:25 PM, Saravana Kannan wrote:
> On 08/01/2014 12:54 PM, Stephen Boyd wrote:
>> On 08/01/14 12:43, Prarit Bhargava wrote:
>>>
>>> On 08/01/2014 03:36 PM, Stephen Boyd wrote:
On 08/01/14 12:15, Prarit Bhargava wrote:
> On 08/01/2014 01:18 PM, Stephen Boyd wrote:
>> On
On 08/01/2014 12:54 PM, Stephen Boyd wrote:
On 08/01/14 12:43, Prarit Bhargava wrote:
On 08/01/2014 03:36 PM, Stephen Boyd wrote:
On 08/01/14 12:15, Prarit Bhargava wrote:
On 08/01/2014 01:18 PM, Stephen Boyd wrote:
On 08/01/14 03:27, Prarit Bhargava wrote:
Can you send me the test and the
On 08/01/14 12:43, Prarit Bhargava wrote:
>
> On 08/01/2014 03:36 PM, Stephen Boyd wrote:
>> On 08/01/14 12:15, Prarit Bhargava wrote:
>>> On 08/01/2014 01:18 PM, Stephen Boyd wrote:
On 08/01/14 03:27, Prarit Bhargava wrote:
> Can you send me the test and the trace of the deadlock? I'm no
On 08/01/2014 03:36 PM, Stephen Boyd wrote:
> On 08/01/14 12:15, Prarit Bhargava wrote:
>>
>> On 08/01/2014 01:18 PM, Stephen Boyd wrote:
>>> On 08/01/14 03:27, Prarit Bhargava wrote:
Can you send me the test and the trace of the deadlock? I'm not creating
it with:
>>> This was w
On 08/01/14 12:15, Prarit Bhargava wrote:
>
> On 08/01/2014 01:18 PM, Stephen Boyd wrote:
>> On 08/01/14 03:27, Prarit Bhargava wrote:
>>> Can you send me the test and the trace of the deadlock? I'm not creating
>>> it with:
>>>
>> This was with conservative as the default, and switching to ondem
On 08/01/2014 01:18 PM, Stephen Boyd wrote:
> On 08/01/14 03:27, Prarit Bhargava wrote:
>>
>> Can you send me the test and the trace of the deadlock? I'm not creating it
>> with:
>>
>
> This was with conservative as the default, and switching to ondemand
>
> # cd /sys/devices/system/cpu/cpu2/
On 08/01/14 03:27, Prarit Bhargava wrote:
>
> Can you send me the test and the trace of the deadlock? I'm not creating it
> with:
>
This was with conservative as the default, and switching to ondemand
# cd /sys/devices/system/cpu/cpu2/cpufreq
# ls
affected_cpus scaling_availabl
On 07/31/2014 08:55 PM, Saravana Kannan wrote:
> On 07/31/2014 03:58 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 06:13 PM, Saravana Kannan wrote:
>>> On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
> On 07/31/2014 01:30 PM, Pr
On 07/31/2014 08:55 PM, Saravana Kannan wrote:
> On 07/31/2014 03:58 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 06:13 PM, Saravana Kannan wrote:
>>> On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
> On 07/31/2014 01:30 PM, Pr
On 07/31/2014 03:58 PM, Prarit Bhargava wrote:
On 07/31/2014 06:13 PM, Saravana Kannan wrote:
On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
Pra
On 07/31/2014 06:13 PM, Saravana Kannan wrote:
> On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 04:38 PM, Saravana Kannan wrote:
>>> On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
>
> Prarit,
>
>
On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
Prarit,
I'm not an expert on sysfs locking, but I would think the specific sysfs lock
would depend o
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
> On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 04:24 PM, Saravana Kannan wrote:
>>>
>>> Prarit,
>>>
>>> I'm not an expert on sysfs locking, but I would think the specific sysfs
>>> lock
>>> would depend on the file/attribute
On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
Prarit,
I'm not an expert on sysfs locking, but I would think the specific sysfs lock
would depend on the file/attribute group. So, can you please try to hotplug a
core in/out (to trigger the POLICY
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
> On 07/31/2014 11:26 AM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 02:38 PM, Rafael J. Wysocki wrote:
>>> On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
> On Thursday,
On 07/31/2014 11:26 AM, Prarit Bhargava wrote:
On 07/31/2014 02:38 PM, Rafael J. Wysocki wrote:
On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
On 07/30/2014 10:16
On 07/31/2014 02:38 PM, Rafael J. Wysocki wrote:
> On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
>>
>> On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
>>> On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
>
> On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
> > On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
> >>
> >> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> >>> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kan
On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
> On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
>>
>> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
> On
On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
>
> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> > On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
> >> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
> >>> On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava
On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
>
On 07/31/2014 06:16 AM, Prarit Bhargava wrote:
>
>
> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
>> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
>
On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
>
On 07/30/2014 07:16 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
On Tuesday, July 29
On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
> > On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
> >>
> >> On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
> >>> On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava
On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
[cut]
This patch effectively reverts commit 955ef483.
The issue re
On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
>
> On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
> > On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
[cut]
> >> This patch effectively reverts commit 955ef483.
> >
> > OK, I'm convinced by this.
> >
> > I suppose w
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
> On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
>> [v2]: Fixed wording of commit, and added additional testing information.
>>
>> A while ago we added a test to mimic some of our users' userspace governor
>> programs which monitor sy
On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
> [v2]: Fixed wording of commit, and added additional testing information.
>
> A while ago we added a test to mimic some of our users' userspace governor
> programs which monitor system behaviour and will switch governors on the
> fly.
[v2]: Fixed wording of commit, and added additional testing information.
A while ago we added a test to mimic some of our users' userspace governor
programs which monitor system behaviour and will switch governors on the
fly. The decision process for this includes looking at time of day,
expected
62 matches
Mail list logo
