Hi Dave,
this is about Venki's and Mathieu's recently sent cleanups.
I'd like to summarize this to help finding a solution:
IMO Venki's approach (making .governor() always be called with
rwsem held) is the cleaner one and this should be the way to
go for .31 and future. This better separates
On Friday 03 July 2009 16:28:43 Pallipadi, Venkatesh wrote:
...
I still do not see the need of dbs_mutex protects data in
dbs_tuners_ins
from concurrent changes, though. If someone enlightens me, that would
be appreciated.
OK. Consider these two happening in parallel.
echo 0
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
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 Wednesday 01 July 2009 01:39:12 Greg KH wrote:
On Tue, Jun 30, 2009 at 07:14:52PM -0400, Mathieu Desnoyers wrote:
* Greg KH (g...@kroah.com) wrote:
I don't see the patch below in Linus's tree. If it's there, what is the
git commit id?
As I pointed out in an earlier reply,
This is about the dead locks happening since cancel_delayed_work_sync()
got added to the ondemand/conservative governors.
I truncated a bit the CC list to most important people and mailing lists.
The patch is intended for 2.6.30 stable, but both patches together did
not get tested yet. If
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.
- rip it out.
CC: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Signed-off-by: Thomas Renninger tr...@suse.de
---
drivers
lock.
Note that all callers to __cpufreq_set_policy are taking the rwsem. All sysfs
callers (writers) hold the write rwsem at the earliest sysfs calling stage.
However, the rwlock write-lock is not needed upon governor stop.
Signed-off-by: Thomas Renninger tr...@suse.de
Acked-by: Venkatesh
On Thursday 25 June 2009 16:01:23 Thomas Renninger wrote:
...
Arggh. I mixed up ker...@stable.org with sta...@kernel.org.
I bounced them there, please correct the address if you answer...
Thomas
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body
On Thursday 25 June 2009 04:25:52 pm Mathieu Desnoyers wrote:
* Thomas Renninger (tr...@suse.de) 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.
- rip it out
On Friday 26 June 2009 12:17:09 am Thomas Renninger wrote:
On Thursday 25 June 2009 04:25:52 pm Mathieu Desnoyers wrote:
* Thomas Renninger (tr...@suse.de) wrote:
Comment from Venkatesh:
...
This mutex is just serializing the changes to those variables. I
could't think of any
userspace modifications will be overriden by
re-initializing the general variables).
This should already be the case.
Signed-off-by: Thomas Renninger tr...@suse.de
---
drivers/cpufreq/cpufreq_ondemand.c | 64 +++--
1 file changed, 13 insertions(+), 51 deletions
14 matches
Mail list logo
