* Pallipadi, Venkatesh (venkatesh.pallip...@intel.com) wrote:
>
>
> >-Original Message-
> >From: Mathieu Desnoyers [mailto:mathieu.desnoy...@polymtl.ca]
> >Sent: Friday, July 03, 2009 8:25 AM
> >To: linux-ker...@vger.kernel.org; Pallipadi, Venkatesh; Dave
> >Jones; Thomas Renninger; cp
* Pallipadi, Venkatesh (venkatesh.pallip...@intel.com) wrote:
>
>
> >-Original Message-
> >From: Mathieu Desnoyers [mailto:mathieu.desnoy...@polymtl.ca]
> >Sent: Friday, July 03, 2009 8:25 AM
> >To: linux-ker...@vger.kernel.org; Pallipadi, Venkatesh; Dave
> >Jones; Thomas Renninger; cp
>-Original Message-
>From: Mathieu Desnoyers [mailto:mathieu.desnoy...@polymtl.ca]
>Sent: Friday, July 03, 2009 8:25 AM
>To: linux-ker...@vger.kernel.org; Pallipadi, Venkatesh; Dave
>Jones; Thomas Renninger; cpuf...@vger.kernel.org;
>kernel-testers@vger.kernel.org; Ingo Molnar; r...@s
>-Original Message-
>From: Mathieu Desnoyers [mailto:mathieu.desnoy...@polymtl.ca]
>Sent: Friday, July 03, 2009 8:25 AM
>To: linux-ker...@vger.kernel.org; Pallipadi, Venkatesh; Dave
>Jones; Thomas Renninger; cpuf...@vger.kernel.org;
>kernel-testers@vger.kernel.org; Ingo Molnar; r...@s
* Pallipadi, Venkatesh wrote:
>
>
> >-Original Message-
> >From: Ingo Molnar [mailto:mi...@elte.hu]
> >Sent: Thursday, July 02, 2009 11:54 PM
> >To: Pallipadi, Venkatesh
> >Cc: Dave Jones; linux-ker...@vger.kernel.org;
> >cpuf...@vger.kernel.org; kernel-testers@vger.kernel.org;
> >
Using the cpufreq_gov_mutex to protect internal governor data structures. The
policy rwsem write lock nests inside this mutex. The policy rwsem is taken in
the timer handler, and therefore cannot be held while doing a sync teardown of
the timer. This cpufreq_gov_mutex lock protects init/teardown
The dbs_mutex is not needed given serialization is provided by the
cpufreq_gov_mutex wrapping all update calls in cpufreq.c.
Signed-off-by: Mathieu Desnoyers
CC: Venkatesh Pallipadi
CC: r...@sisk.pl
CC: mi...@elte.hu
CC: Shaohua Li
CC: Pekka Enberg
CC: Dave Young
CC: "Rafael J. Wysocki"
CC:
OK, I've tried to clean it up the best I could, but please test this with
concurrent cpu hotplug and cpufreq add/remove in loops. I'm sure we will make
other interesting findings.
This is step one of fixing the overall locking dependency mess in cpufreq.
Signed-off-by: Mathieu Desnoyers
CC: Venk
commit 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
teardown. To make a long story short, the rwlock write-lock causes a circular
dependency with cancel_delayed_work_sync(), because the timer handler takes the
read lock.
N
(sorry, quilt mail problems in the previous post, here is the resend)
Hi,
Here is a patchset applying on 2.6.30 which should fix the cpufreq locking
dependency. Sadly, my two main test machines does not seem to support cpufreq,
so I have only been able to perform very light testing. (I can't affo
commit 42a06f2166f2f6f7bf04f32b4e823eacdceafdc9
Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
teardown. To make a long story short, the rwlock write-lock causes a circular
dependency with cancel_delayed_work_sync(), because the timer handler takes the
read lock.
N
Hi,
> OK, I see another gotcha added by recent changes, we need to explicitly
> initialize rq_in_flight variables now. Revised patch below..
>
Sorry, STD also not work. if apply this patch, the same problem as not
apply it, it stopped at:
...
PM: Crete hibernation image:
PM: Need to copy ... p
Hi,
Here is a patchset applying on 2.6.30 which should fix the cpufreq locking
dependency. Sadly, my two main test machines does not seem to support cpufreq,
so I have only been able to perform very light testing. (I can't afford to lock
down my laptop right now).
I went for the most straightforw
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>-Original Message-
>From: Ingo Molnar [mailto:mi...@elte.hu]
>Sent: Thursday, July 02, 2009 11:54 PM
>To: Pallipadi, Venkatesh
>Cc: Dave Jones; linux-ker...@vger.kernel.org;
>cpuf...@vger.kernel.org; kernel-testers@vger.kernel.org;
>Rafael J. Wysocki; Dave Young; Pekka Enberg; Mathie
>-Original Message-
>From: Thomas Renninger [mailto:tr...@suse.de]
>Sent: Friday, July 03, 2009 4:41 AM
>To: Pallipadi, Venkatesh
>Cc: Dave Jones; linux-ker...@vger.kernel.org;
>cpuf...@vger.kernel.org; kernel-testers@vger.kernel.org; Ingo
>Molnar; Rafael J. Wysocki; Dave Young; Pekka
* Ingo Molnar (mi...@elte.hu) wrote:
>
> * venkatesh.pallip...@intel.com wrote:
>
> > Since recent chanegs to ondemand and conservative governor, there
> > have been multiple reports of lockdep issues in cpufreq. Patch
> > series takes care of these problems.
> >
> > This is the next attempt
On Friday 03 July 2009 05:58:25 Wu Zhangjin wrote:
> On Thu, 2009-07-02 at 18:13 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 02 July 2009 03:46:43 Wu Zhangjin wrote:
> > > On Wed, 2009-07-01 at 18:29 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Wednesday 01 July 2009 18:21:25 Bart
Oh dear, again with the correct lkml list address in CC, please
do not answer on the previous mail...
Hi,
inspired by Rafaels talk about covering kernel code for regression
testing and the need to be able to debug tunables in the ondemand
governor, Christian produced this IMO excellent micro code
Hi,
inspired by Rafaels talk about covering kernel code for regression
testing and the need to be able to debug tunables in the ondemand
governor, Christian produced this IMO excellent micro code benchmark.
What is this benchmark for:
- Identify worst case performance loss when doing dynamic fr
On Friday 03 July 2009 02:08:30 venkatesh.pallip...@intel.com wrote:
> Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
> much needed to properly cleanup ondemand timer, opened-up a can of worms
> related to locking dependencies in cpufreq.
>
> Patch here defines the need for d
Hi Pavel,
On Tuesday 30 June 2009 08:33:39 Pavel Machek wrote:
> On Thu 2009-06-25 16:01:24, Thomas Renninger wrote:
> > Comment from Venkatesh:
> > ...
> > This mutex is just serializing the changes to those variables. I could't
> > think of any functionality issues of not having the lock as such
Hi David,
On Wed, 1 Jul 2009, Pekka Enberg wrote:
>> Lets go with the slab_out_of_memory() patch you outlined in a previous
>> post and implement the slub_debug=p thing Christoph suggested. I think
>> it's the best compromise at this point. When you guys finally see the
>> light, we can always cha
23 matches
Mail list logo