[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090703140637.GB10256@Krystal>
Date: Fri, 3 Jul 2009 10:06:37 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: Ingo Molnar <mingo@...e.hu>
Cc: venkatesh.pallipadi@...el.com, Dave Jones <davej@...hat.com>,
linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
kernel-testers@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
Dave Young <hidave.darkstar@...il.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Thomas Renninger <trenn@...e.de>
Subject: Re: [patch 0/4] Take care of cpufreq lockdep issues (take 2)
* Ingo Molnar (mingo@...e.hu) wrote:
>
> * venkatesh.pallipadi@...el.com <venkatesh.pallipadi@...el.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, which was not a
> > complete fix.
> > http://lkml.indiana.edu/hypermail/linux/kernel/0906.3/01073.html
> >
> > I am currently running some stress tests to make sure there are no
> > issues with these patches. But, wanted to send them out for
> > review/comments/testing before I head out for the long weekend.
> >
> > If this patchset seems sane, the first patch in the patchset
> > should also get into 30.stable.
>
> Btw., FYI, because my test-systems were frequently triggering those
> bugs, i kept testing the following series from you and Mathieu in
> -tip:
>
> ecf8b04: cpufreq: Define dbs_mutex purpose and cleanup its usage conservative gov
> b08c597: cpufreq: Define dbs_mutex purpose and cleanup its usage
> 0807e30: cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)
>
> So that fix-series, while probably not complete (given that you sent
> a v2 series), worked well in practice and gets my:
>
> Tested-by: Ingo Molnar <mingo@...e.hu>
>
> Is the delta between this (tested) series and your v2 version
> significant? If not it might make sense to shape it as a delta patch
> to the v1 series, if that looks clean enough - to preserve testing
> results.
The delta is very significant. The purpose of each lock changes quite a
bit. I'm preparing a patch serie that should just fix the problem
without significant locking semantic modification.
(not that I have time to do this, but I end up spending more time
looking at the proposed solutions than doing it..) ;)
Mathieu
>
> Ingo
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists