This patchset adds the core IPS driver to drivers/platform/x86, along with
some helper code in the timer subsystem to allow for deferrable on-stack
timers.

Note that the deferrable timers don't actually work at this point; I'm
probably just doing something silly in the IPS driver in using them, but
it's possible the core code is wrong too, I'm hoping for some review
there (so testing thus far has been with a fixed sample rate).

Also note that this patchset doesn't include the i915 specific bits for
monitoring power consumption; I'm still debugging those (my current
platform overreports power by several watts; I'm hoping a production
platform will return reasonable values) but expect to be able to post
them soon.  With the combination of this driver and the i915 code, I
expect significant GPU performance gains; early measurements with simple
loads show about a 15% improvement, but I've heard reports of even
higher.

Anyway, please take a look and let me know what needs fixing or how I
might make this a better driver.

Thanks,
Jesse

--

[ message continues ]

Ok, if this driver screws up will

a) cpu/gpu protect itself from damage by overheat?

b) cpu/gpu protect itself from incorrect operation resulting from



return (averun > 1); ?

But this is wrong test, anyway. One process waiting for disk, and you

Merge above four functions into two, by having 'enable' parameter?




printk?




I wonder if we should have milliwatt_t, msec_t and similar, to aid

Please no unicode at least in user interfaces. Ouch and it is subtly
wrong. You really want "%d.%02d".

Ok, interesting. What kind of speedup can it bring?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

On Tue, 13 Apr 2010 21:24:53 +0200


The CPU will end up throttling itself, reducing performance to keep
within its power budget.  The GPU will just end up hanging if it

They would be, but these docs are only available under NDA.  If you
have a sales or technical contact you can use the numbers here to get

Yes, I'm happy to have a better test here.  Not that it matters *too*
much though; we'll allocate more power budget to the CPU, but it will
only use it if needed.  Allocating it more power just gives the turbo
boost capability additional frequency bins.  The CPU won't actually use

Accesses to these should be protected by the parameter lock.  And I
have two variables to differentiate between the hardware being enabled
vs. the software requesting an enable/disable.  They could probably be

This part is useless without the corresponding GPU power patch; that'll

Probably wouldn't hurt; but I've given myself some leeway here; if
we're near the limit I'd like this check to return true and forcibly
throttle things back, just to make extra sure we don't go over budget.
On most standard voltage platforms this won't really matter, but on
tightly designed ultra-low voltage platforms it's important we never

Yes, I don't believe we'll be doing 4 core Arrandale MCPs.  And



For the CPU the perf upside isn't that great, maybe 5% or so, and only
with very specific workloads that take advantage of turbo boost.  For
graphics the upside is significant, at least 15% in my basic tests so
far, but Eric and Keith have measured 3x gains in some cases.

-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

In some cases (for instance with kernel threads) it may be desireable to
use on-stack deferrable timers to get their power saving benefits.  Add
interfaces to support this for the IPS driver.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 include/linux/timer.h |   15 +++++++++++++++
 kernel/timer.c        |   13 +++++++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/include/linux/timer.h b/include/linux/timer.h
index a2d1eb6..b9bc8e1 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -94,6 +94,13 @@ void init_timer_deferrable_key(struct timer_list *timer,
 		setup_timer_on_stack_key((timer), #timer, &__key,	\
 					 (fn), (data));			\
 	} while (0)
+#define setup_deferrable_timer_on_stack(timer, fn, data)		\
+	do {								\
+		static struct lock_class_key __key;			\
+		setup_deferrable_timer_on_stack_key((timer), #timer,	\
+						    &__key, (fn),	\
+						    (data));		\
+	} while (0)
 #else
 #define init_timer(timer)\
 	init_timer_key((timer), NULL, NULL)
@@ -105,6 +112,8 @@ void init_timer_deferrable_key(struct timer_list *timer,
 	setup_timer_key((timer), NULL, NULL, (fn), (data))
 #define setup_timer_on_stack(timer, fn, data)\
 	setup_timer_on_stack_key((timer), NULL, NULL, (fn), (data))
+#define setup_deferrable_timer_on_stack(timer, fn, data)\
+	setup_deferrable_timer_on_stack_key((timer), NULL, NULL, (fn), (data))
 #endif
 
 #ifdef CONFIG_DEBUG_OBJECTS_TIMERS
@@ -144,6 +153,12 @@ static inline void setup_timer_on_stack_key(struct timer_list *timer,
 	init_timer_on_stack_key(timer, name, key);
 }
 
+extern void setup_deferrable_timer_on_stack_key(struct timer_list *timer,
+						const char *name,
+						struct lock_class_key *key,
+						void (*function)(unsigned long),
+						unsigned long data);
+
 /**
  * timer_pending - is a timer pending?
  * @timer: the timer in question
diff --git a/kernel/timer.c b/kernel/timer.c
index c61a794..a7b964a 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ ...
[ message continues ]