[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090703143705.997230857@polymtl.ca>
Date: Fri, 03 Jul 2009 10:37:06 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: linux-kernel@...r.kernel.org,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Dave Jones <davej@...hat.com>,
Thomas Renninger <trenn@...e.de>, cpufreq@...r.kernel.org,
kernel-testers@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
rjw@...k.pl, Dave Young <hidave.darkstar@...il.com>,
Pekka Enberg <penberg@...helsinki.fi>
Subject: [patch 2.6.30 0/4] Fix cpufreq locking dependency
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 straightforward fix I could think of and kept the current
locking structure. As you will see, the second patch cleans up the error
handling paths of cpufreq add dev, which were a total mess.
As a general recommendation, creating scripts which does, concurrently :
cpu hotplug up/down
cpufreq sysfs actions
change between cpufreq governors
add governors on random CPU numbers
will likely help stress-testing cpufreq locking. I really did not like what I've
seen there. It looked _very_ fragile.
Hopefully this will be better with this patches, but again, testing is welcome.
Thanks,
Mathieu
--
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