Re: [ACPI] acpi_processor_set_power_policy

From: Kenneth Parrish
Date: Wed Jun 08 2005 - 19:22:51 EST


-=> Kenneth Parrish wrote to All <=-

KP> SEEN-BY: 8/1 2 2003
KP> PATH: 8/2003 1 2
KP> MSGID: 8:8/2003 122ea9cd
KP> TZUTC: -0600
KP> CHARSET: PC-8
KP> From: Kenneth Parrish <Kenneth.Parrish@xxxxxxxxxxxxxx>

KP> # readprofile -r ; sleep 1 ; readprofile -m /boot/System.map
| sort -nr

KP> 527 total 0.0003
KP> 502 acpi_processor_set_power_policy 2.6989
KP> 7 sort 0.0208
KP> 7 release_task 0.0208
KP> 4 zone_watermark_ok 0.0208
KP> 3 do_page_fault 0.0021
KP> 1 unmap_page_range 0.0057
KP> 1 show_free_areas 0.0013
KP> 1 do_file_page 0.0048
KP> 1 buffered_rmqueue 0.0020

KP> Should acpi_processor_set_power_policy be called this often?

KP> Kernel: 2.6.12-rc5-git9 # define HZ 500
KP> <include/asm-i386/param.h> Computer: Cyrix MII and VIA MVP3,
KP> e-machines '99 dmesg.. Kernel command line:
KP> BOOT_IMAGE=2.6.12-rc5-git9 ro root=301 clock=tsc elevator=
KP> deadline lpj=376832 profile=2
KP> kernel profiling enabled (shift: 2)

KP> More information and at request.

KP> ... A: 6-1/2" x 6-1/2" x 2" Q: How big is the Mac Mini?
KP> -+- MultiMail/Linux v0.46 [currently BlueWave packet type]
KP> -
KP> To unsubscribe from this list: send the line "unsubscribe
KP> linux-kernel" in the body of a message to
KP> majordomo@xxxxxxxxxxxxxxx More majordomo info at
KP> http://vger.kernel.org/majordomo-info.html Please read the
KP> FAQ at http://www.tux.org/lkml/

KP> --- BBBS/NT v4.01 Flag-5
KP> * Origin: FamilyNet Sponsored by
KP> http://www.christian-wellness.net (8:8/2003)

I noticed the subject function appears in drivers/acpi/processor_idle.c
and tried a couple of things. Look OK? comments on the [misguided?] patch?
:-)
This seems to cut the acpi function time reported by readprofile
~85%, and changes the function from acpi_processor_set_power_policy to
acpi_processor_idle.

260 total 0.0002
251 acpi_processor_idle 0.4163
4 __copy_to_user_ll 0.0625
3 __unhash_process 0.0170
1 zap_page_range 0.0042
1 create_elf_tables 0.0010

Note the tick has changed from 500 -> 250 HZ.

Apparently C1<->C2 transition works OK still:

active state: C2
max_cstate: C8
bus master activity: 00000000
states:
C1: type[C1] promotion[C2] demotion[--] latency[000]
usage[00004380]
*C2: type[C2] promotion[--] demotion[C1] latency[100]
usage[00381931]

--- processor_idle.c.orig 2005-06-08 13:05:11.000000000 -0500
+++ processor_idle.c 2005-06-08 16:59:06.000000000 -0500
@@ -67,7 +67,7 @@
* 100 HZ: 0x0000000F: 4 jiffies = 40ms
* reduce history for more aggressive entry into C3
*/
-static unsigned int bm_history = (HZ >= 800 ? 0xFFFFFFFF : ((1U << (HZ / 25))
- 1));
+static unsigned int bm_history = (HZ >= 500 ? 0xFFFFFFFF : ((1U << (HZ / 25))
- 1));
module_param(bm_history, uint, 0644);
/* --------------------------------------------------------------------------
Power Management
@@ -336,7 +336,7 @@
cx->promotion.count++;
cx->demotion.count = 0;
if (cx->promotion.count >= cx->promotion.threshold.coun
- if (pr->flags.bm_check) {
+ if (unlikely(pr->flags.bm_check)) {
if (!(pr->power.bm_activity & cx->promo
next_state = cx->promotion.stat
goto end;
@@ -382,7 +382,7 @@
* If we're going to start using a new Cx state we must clean up
* from the previous and prepare to use the new.
*/
- if (next_state != pr->power.state)
+ if (unlikely(next_state != pr->power.state))
acpi_processor_power_activate(pr, next_state);

return;
@@ -446,8 +446,6 @@
cx->demotion.state = lower;
cx->demotion.threshold.ticks = cx->latency_ticks;
cx->demotion.threshold.count = 1;
- if (cx->type == ACPI_STATE_C3)
- cx->demotion.threshold.bm = bm_history;
}

lower = cx;
@@ -462,12 +460,7 @@
if (higher) {
cx->promotion.state = higher;
cx->promotion.threshold.ticks = cx->latency_ticks;
- if (cx->type >= ACPI_STATE_C2)
- cx->promotion.threshold.count = 4;
- else
cx->promotion.threshold.count = 10;
- if (higher->type == ACPI_STATE_C3)
- cx->promotion.threshold.bm = bm_history;
}

higher = cx;

... "Will he say nasty things at my funeral?" -- Ezra Pound
--- MultiMail/Linux v0.46
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/