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
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 lock
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
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 ear
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
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 issue
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
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
Acked-by: Venkatesh Pallipadi
---
drivers/cpufreq/cpufreq.c | 13
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
Signed-off-by: Thomas Renninger
---
drivers/cpufreq/cpufreq_conservative.
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 someone
time for implementation due to my thesis, but I'll
> > be happy to review a patch.
> >
>
> How about below patch on top of Mathieu's patch here
> http://marc.info/?l=linux-kernel&m=124448150529838&w=2
>
> [PATCH] cpufreq: Eliminate lockdep issue with dbs_
14 matches
Mail list logo
