* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
[not found] <20060904131027.GD6279@ucw.cz>
@ 2006-09-05 8:28 ` Pavel Machek
2006-09-05 8:53 ` Pavel Machek
0 siblings, 1 reply; 7+ messages in thread
From: Pavel Machek @ 2006-09-05 8:28 UTC (permalink / raw)
To: abelay, len.brown, linux-acpi, linux-kernel, linux, arjan
Hi!
> This patch takes advantage of the infrastructure introduced in the last
> patch, and allows the processor idle algorithm to proactively choose a
> c-state based on the time the next timer interrupt is expected to occur.
> It preserves the residency metric, so the algorithm should, in theory,
> remain effective against bursts of activity from other interrupt
> sources.
>
> This patch is mostly intended to be illustrative. There may be some
> "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> implementing this more cleanly.
>
> Cheers,
> Adam
> --- a/kernel/timer.c 2006-08-03 13:39:22.000000000 -0400
> +++ b/kernel/timer.c 2006-08-28 17:16:36.000000000 -0400
> @@ -41,6 +41,9 @@
> #include <asm/timex.h>
> #include <asm/io.h>
>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/processor.h>
> +
I sense a problem here, like broken compilation for all non-x86
platforms.
> @@ -1175,6 +1178,10 @@
> {
> struct task_struct *p = current;
> int cpu = smp_processor_id();
> + struct acpi_processor *pr = processors[cpu];
> +
> + if (pr)
> + pr->power.timer_tick = inl(acpi_fadt.xpm_tmr_blk.address);
>
This probably needs to be encapsulated, somehow.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
2006-09-05 8:28 ` [RFC][PATCH 2/2] ACPI: handle timer ticks proactively Pavel Machek
@ 2006-09-05 8:53 ` Pavel Machek
2006-09-05 9:03 ` Pavel Machek
0 siblings, 1 reply; 7+ messages in thread
From: Pavel Machek @ 2006-09-05 8:53 UTC (permalink / raw)
To: abelay, len.brown, linux-acpi, linux-kernel, linux, arjan
Hi!
> > This patch takes advantage of the infrastructure introduced in the last
> > patch, and allows the processor idle algorithm to proactively choose a
> > c-state based on the time the next timer interrupt is expected to occur.
> > It preserves the residency metric, so the algorithm should, in theory,
> > remain effective against bursts of activity from other interrupt
> > sources.
> >
> > This patch is mostly intended to be illustrative. There may be some
> > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > implementing this more cleanly.
Okay, just to get you some feedback:
It seems to change things a _lot_. Power consumption with usb modules
loaded went from 14315mW to 13800mW -- that is huge
deal. Unfortunately something strange is going on: with stock kernel,
power consumption is mostly constant. With your patch, it varies a
lot, at 2 second timescale.
Power consumption with usb unloaded (only way to get reasonable power
on x60) went from stable 10450mW to something rapidly changing, and
probably even worse than original:
current average
-11200 mW avg -11274 mW
-10505 mW avg -11251 mW
-11701 mW avg -11238 mW
-11975 mW avg -11348 mW
-10432 mW avg -11313 mW
-11944 mW avg -11422 mW
-10683 mW avg -11504 mW
-10682 mW avg -11457 mW
-10402 mW avg -11432 mW
-11913 mW avg -11317 mW
-12004 mW avg -11541 mW
-12004 mW avg -11661 mW
-11945 mW avg -11781 mW
-11943 mW avg -11824 mW
-12577 mW avg -11891 mW
-12004 mW avg -11930 mW
-12019 mW avg -11944 mW
-11972 mW avg -12002 mW
-12004 mW avg -11990 mW
-11913 mW avg -12032 mW
-11083 mW avg -11903 mW
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
2006-09-05 8:53 ` Pavel Machek
@ 2006-09-05 9:03 ` Pavel Machek
2006-09-05 15:16 ` Adam Belay
0 siblings, 1 reply; 7+ messages in thread
From: Pavel Machek @ 2006-09-05 9:03 UTC (permalink / raw)
To: abelay, len.brown, linux-acpi, linux-kernel, linux, arjan
Hi!
> > > This patch takes advantage of the infrastructure introduced in the last
> > > patch, and allows the processor idle algorithm to proactively choose a
> > > c-state based on the time the next timer interrupt is expected to occur.
> > > It preserves the residency metric, so the algorithm should, in theory,
> > > remain effective against bursts of activity from other interrupt
> > > sources.
> > >
> > > This patch is mostly intended to be illustrative. There may be some
> > > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > > implementing this more cleanly.
>
> Okay, just to get you some feedback:
>
> It seems to change things a _lot_. Power consumption with usb modules
> loaded went from 14315mW to 13800mW -- that is huge
> deal. Unfortunately something strange is going on: with stock kernel,
> power consumption is mostly constant. With your patch, it varies a
> lot, at 2 second timescale.
>
> Power consumption with usb unloaded (only way to get reasonable power
> on x60) went from stable 10450mW to something rapidly changing, and
> probably even worse than original:
I also noticed that with your patch, bus master activity tends to be constant?!
root@amd:/data/l/tp/tp_smapi-0.22# cat /proc/acpi/processor/CPU0/power
active state: C3
max_cstate: C8
bus master activity: 37244
states:
C1: type[C1] latency[000] usage[00000067]
duration[00000000000000000067]
C2: type[C2] latency[001] usage[00042173]
duration[00000000000454647687]
*C3: type[C3] latency[057] usage[00290242]
duration[00000000003402855375]
root@amd:/data/l/tp/tp_smapi-0.22# cat /proc/acpi/processor/CPU0/power
active state: C3
max_cstate: C8
bus master activity: 37244
states:
C1: type[C1] latency[000] usage[00000067]
duration[00000000000000000067]
C2: type[C2] latency[001] usage[00042274]
duration[00000000000454688808]
*C3: type[C3] latency[057] usage[00305466]
duration[00000000003595077816]
root@amd:/data/l/tp/tp_smapi-0.22#
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
2006-09-05 9:03 ` Pavel Machek
@ 2006-09-05 15:16 ` Adam Belay
2006-09-06 10:54 ` Pavel Machek
0 siblings, 1 reply; 7+ messages in thread
From: Adam Belay @ 2006-09-05 15:16 UTC (permalink / raw)
To: Pavel Machek; +Cc: len.brown, linux-acpi, linux-kernel, linux, arjan
On Tue, 2006-09-05 at 11:03 +0200, Pavel Machek wrote:
> Hi!
>
> > > > This patch takes advantage of the infrastructure introduced in the last
> > > > patch, and allows the processor idle algorithm to proactively choose a
> > > > c-state based on the time the next timer interrupt is expected to occur.
> > > > It preserves the residency metric, so the algorithm should, in theory,
> > > > remain effective against bursts of activity from other interrupt
> > > > sources.
> > > >
> > > > This patch is mostly intended to be illustrative. There may be some
> > > > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > > > implementing this more cleanly.
> >
> > Okay, just to get you some feedback:
> >
> > It seems to change things a _lot_. Power consumption with usb modules
> > loaded went from 14315mW to 13800mW -- that is huge
> > deal. Unfortunately something strange is going on: with stock kernel,
> > power consumption is mostly constant. With your patch, it varies a
> > lot, at 2 second timescale.
> >
> > Power consumption with usb unloaded (only way to get reasonable power
> > on x60) went from stable 10450mW to something rapidly changing, and
> > probably even worse than original:
>
> I also noticed that with your patch, bus master activity tends to be constant?!
Is this the case even when userspace touches the disk? On my hardware I
see a constant flow of short BM activity bursts.
Thanks,
Adam
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
2006-09-05 15:16 ` Adam Belay
@ 2006-09-06 10:54 ` Pavel Machek
0 siblings, 0 replies; 7+ messages in thread
From: Pavel Machek @ 2006-09-06 10:54 UTC (permalink / raw)
To: Adam Belay; +Cc: len.brown, linux-acpi, linux-kernel, linux, arjan
Hi!
> > > Okay, just to get you some feedback:
> > >
> > > It seems to change things a _lot_. Power consumption with usb modules
> > > loaded went from 14315mW to 13800mW -- that is huge
> > > deal. Unfortunately something strange is going on: with stock kernel,
> > > power consumption is mostly constant. With your patch, it varies a
> > > lot, at 2 second timescale.
> > >
> > > Power consumption with usb unloaded (only way to get reasonable power
> > > on x60) went from stable 10450mW to something rapidly changing, and
> > > probably even worse than original:
> >
> > I also noticed that with your patch, bus master activity tends to be constant?!
>
> Is this the case even when userspace touches the disk? On my hardware I
> see a constant flow of short BM activity bursts.
Disk was active (like once 5 seconds some small access)...
Pavel
--
Thanks, Sharp!
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
@ 2006-08-29 20:51 Adam Belay
2006-10-16 4:59 ` Len Brown
0 siblings, 1 reply; 7+ messages in thread
From: Adam Belay @ 2006-08-29 20:51 UTC (permalink / raw)
To: Len Brown; +Cc: ACPI-ML, Linux Kernel ML, Dominik Brodowski, Arjan van de Ven
Hi All,
This patch takes advantage of the infrastructure introduced in the last
patch, and allows the processor idle algorithm to proactively choose a
c-state based on the time the next timer interrupt is expected to occur.
It preserves the residency metric, so the algorithm should, in theory,
remain effective against bursts of activity from other interrupt
sources.
This patch is mostly intended to be illustrative. There may be some
"#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
implementing this more cleanly.
Cheers,
Adam
Patch is against 2.6.18-rc4.
Signed-off-by: Adam Belay <abelay@novell.com>
---
drivers/acpi/processor_idle.c | 17 +++++++++++++++++
include/acpi/processor.h | 2 ++
kernel/timer.c | 7 +++++++
3 files changed, 26 insertions(+)
--- a/drivers/acpi/processor_idle.c 2006-08-28 17:14:54.000000000 -0400
+++ b/drivers/acpi/processor_idle.c 2006-08-28 17:29:21.000000000 -0400
@@ -64,6 +64,7 @@
* Currently, we aim for the entry/exit latency to be 20% of measured residency.
*/
#define RESIDENCY_TO_LATENCY_RATIO 5
+#define TIMER_TICKS (PM_TIMER_FREQUENCY / HZ)
/* --------------------------------------------------------------------------
Power Management
@@ -271,6 +272,22 @@
int count = min(pr->power.count, (int) max_cstate);
cx = &pr->power.states[state_idx];
+ /*
+ * We are proactive with timer interrupts. After a timer
+ * interrupt has occurred the previous sleep_ticks value is
+ * restored.
+ */
+ if (pr->power.pretimer_last_ticks) {
+ sleep_ticks = pr->power.pretimer_last_ticks;
+ pr->power.pretimer_last_ticks = 0;
+ }
+ t1 = inl(acpi_fadt.xpm_tmr_blk.address);
+ i = TIMER_TICKS - t1 + pr->power.timer_tick;
+ if (i < sleep_ticks) {
+ pr->power.pretimer_last_ticks = sleep_ticks;
+ sleep_ticks = i;
+ }
+
if (cx->target_ticks < sleep_ticks) { /* promotion */
for (i = state_idx + 1; i <= count; i++) {
cx = &pr->power.states[i];
--- a/kernel/timer.c 2006-08-03 13:39:22.000000000 -0400
+++ b/kernel/timer.c 2006-08-28 17:16:36.000000000 -0400
@@ -41,6 +41,9 @@
#include <asm/timex.h>
#include <asm/io.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/processor.h>
+
#ifdef CONFIG_TIME_INTERPOLATION
static void time_interpolator_update(long delta_nsec);
#else
@@ -1175,6 +1178,10 @@
{
struct task_struct *p = current;
int cpu = smp_processor_id();
+ struct acpi_processor *pr = processors[cpu];
+
+ if (pr)
+ pr->power.timer_tick = inl(acpi_fadt.xpm_tmr_blk.address);
/* Note: this timer irq context must be accounted for as well. */
if (user_tick)
--- a/include/acpi/processor.h 2006-08-28 17:14:54.000000000 -0400
+++ b/include/acpi/processor.h 2006-08-28 17:20:25.000000000 -0400
@@ -60,6 +60,8 @@
u32 bm_activity;
u32 bm_veto_state;
u32 last_ticks;
+ u32 timer_tick;
+ u32 pretimer_last_ticks;
int count;
struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
};
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC][PATCH 2/2] ACPI: handle timer ticks proactively
2006-08-29 20:51 Adam Belay
@ 2006-10-16 4:59 ` Len Brown
0 siblings, 0 replies; 7+ messages in thread
From: Len Brown @ 2006-10-16 4:59 UTC (permalink / raw)
To: Adam Belay; +Cc: ACPI-ML, Linux Kernel ML, Dominik Brodowski, Arjan van de Ven
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
I ran bltk this patch vs 2.6.18.1 on a Dell i6400 Core Duo laptop.
Initial result (1 measurement of each kernel) is that
battery life is unchanged, but response time improves with the new patch.
Summary files attached.
thanks,
-Len
[-- Attachment #2: Report.2.6.8.1-amb2 --]
[-- Type: text/plain, Size: 4020 bytes --]
Workload
Workload : Open Office (office) 1.0.4
System
Manufacturer : Dell Inc.
Product Name : MM061
System Release : SUSE LINUX 10.1 (i586)
Kernel Release : 2.6.18.1-dirty
CPU
CPU : 0
CPU Model : Genuine Intel(R) CPU T2500 @ 2.00GHz
Cache Size : 2048 KB
Num Logical : 2
Governor : ondemand
Timer : 0.00
Interrupts : 8.93
Load : 1.58%
Max Frequecy : 2000000
Min Frequency : 1000000
Average Frequency : 1017733
Bus Master Activity : 0.00
C1 : 31.88
C2 : 32.65
C3 : 260.95
P0 : 1.69
P1 : 0.09
P2 : 0.05
P3 : 98.16
CPU
CPU : 1
CPU Model : Genuine Intel(R) CPU T2500 @ 2.00GHz
Cache Size : 2048 KB
Num Logical : 2
Governor : ondemand
Timer : 249.98
Interrupts : 2.82
Load : 1.92%
Max Frequecy : 2000000
Min Frequency : 1000000
Average Frequency : 1017733
Bus Master Activity : 0.00
C1 : 4.19
C2 : 5.03
C3 : 287.82
P0 : 1.69
P1 : 0.09
P2 : 0.05
P3 : 98.16
Memory
Memory Size : 2064260 kB
Swap Size : 2104472 kB
Max Memory : 664196 kB
Max Swap : 0 kB
Display
Grafic Model : Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Display Size : 1280x800x16
Display State : on 100.00%, standby 0.00%, suspend 0.00%, off 0.00%
HD
HD Model : HTS721010G9SA00
HD Size : 100030 MBytes (100 GB)
HD RPM : -
HD Reads : 0.00 per sec
HD Writes : 2.77 per sec
HD State : active/idle 0.00%, standby 100.00%, sleeping 0.00%
BAT
Battery Model : DELLUD2646
Charging State : charged
Design Voltage : 11100 mV
Design Capacity : 53280 mWh (100.00%)
Last Full Capacity : 48384 mWh (90.81%)
Remaining Capacity : 53280 mWh (100.00%)
Start Capacity : 53280 mWh (100.00%)
Finish Capacity : 11 mWh (0.02%)
Drain Rate : 16.31 W (4.53 mWh per sec)
Design Battery Rating : 196 min (03:16:02)
Rating
Battery Rating : 196 min (03:16:00)
Iterations : 16.33
Cycle Time : 720.00 sec
Work Time : 481.48 sec
Response Time : 8.28 sec
Score : 289.92
Source
Source : results.office.amb2a
Comment
Comment : -
Test Result
Result : Passed
[-- Attachment #3: Report.2.6.8.1 --]
[-- Type: text/plain, Size: 4013 bytes --]
Workload
Workload : Open Office (office) 1.0.4
System
Manufacturer : Dell Inc.
Product Name : MM061
System Release : SUSE LINUX 10.1 (i586)
Kernel Release : 2.6.18.1
CPU
CPU : 0
CPU Model : Genuine Intel(R) CPU T2500 @ 2.00GHz
Cache Size : 2048 KB
Num Logical : 2
Governor : ondemand
Timer : 0.00
Interrupts : 11.84
Load : 2.18%
Max Frequecy : 2000000
Min Frequency : 1000000
Average Frequency : 1016988
Bus Master Activity : 0.00
C1 : 0.00
C2 : 10.39
C3 : 565.52
P0 : 1.63
P1 : 0.09
P2 : 0.03
P3 : 98.25
CPU
CPU : 1
CPU Model : Genuine Intel(R) CPU T2500 @ 2.00GHz
Cache Size : 2048 KB
Num Logical : 2
Governor : ondemand
Timer : 249.98
Interrupts : 0.00
Load : 1.43%
Max Frequecy : 2000000
Min Frequency : 1000000
Average Frequency : 1016988
Bus Master Activity : 0.00
C1 : 0.00
C2 : 11.11
C3 : 323.20
P0 : 1.63
P1 : 0.09
P2 : 0.03
P3 : 98.25
Memory
Memory Size : 2064260 kB
Swap Size : 2104472 kB
Max Memory : 658288 kB
Max Swap : 0 kB
Display
Grafic Model : Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Display Size : 1280x800x16
Display State : on 100.00%, standby 0.00%, suspend 0.00%, off 0.00%
HD
HD Model : HTS721010G9SA00
HD Size : 100030 MBytes (100 GB)
HD RPM : -
HD Reads : 0.07 per sec
HD Writes : 2.76 per sec
HD State : active/idle 0.00%, standby 100.00%, sleeping 0.00%
BAT
Battery Model : DELLUD2646
Charging State : charged
Design Voltage : 11100 mV
Design Capacity : 53280 mWh (100.00%)
Last Full Capacity : 48362 mWh (90.77%)
Remaining Capacity : 53280 mWh (100.00%)
Start Capacity : 53280 mWh (100.00%)
Finish Capacity : 55 mWh (0.10%)
Drain Rate : 16.29 W (4.53 mWh per sec)
Design Battery Rating : 196 min (03:16:12)
Rating
Battery Rating : 196 min (03:16:00)
Iterations : 16.33
Cycle Time : 720.00 sec
Work Time : 482.11 sec
Response Time : 8.87 sec
Score : 270.59
Source
Source : results.office.ref
Comment
Comment : -
Test Result
Result : Passed
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-10-16 4:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060904131027.GD6279@ucw.cz>
2006-09-05 8:28 ` [RFC][PATCH 2/2] ACPI: handle timer ticks proactively Pavel Machek
2006-09-05 8:53 ` Pavel Machek
2006-09-05 9:03 ` Pavel Machek
2006-09-05 15:16 ` Adam Belay
2006-09-06 10:54 ` Pavel Machek
2006-08-29 20:51 Adam Belay
2006-10-16 4:59 ` Len Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox