* venkatesh.pallip...@intel.com 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 following the one here,
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 change it
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.
-
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
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
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
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 Bartlomiej
* Ingo Molnar (mi...@elte.hu) wrote:
* venkatesh.pallip...@intel.com 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
-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
-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; Mathieu
--
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
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
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 ...
(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
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.
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
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 mathieu.desnoy...@polymtl.ca
CC: Venkatesh Pallipadi venkatesh.pallip...@intel.com
CC: r...@sisk.pl
CC: mi...@elte.hu
CC: Shaohua Li
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
* Pallipadi, Venkatesh venkatesh.pallip...@intel.com 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;
-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;
-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;
* 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;
* 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;
23 matches
Mail list logo
