+ acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

+ acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[akpm]

The patch titled
     ACPI: keep track of timer broadcasting, fix
has been added to the -mm tree.  Its filename is
     acpi-keep-track-of-timer-broadcasting-fix.patch

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

------------------------------------------------------
Subject: ACPI: keep track of timer broadcasting, fix
From: Ingo Molnar <mingo@elte.hu>

Many BIOSes offer C2 state but in reality they enter C3 - and hence the
local APIC stops working.  So make acpi_timer_check_state() more
conservative and assume that the lapic-stops workaround is needed even in
C2.

This is a bug in the upstream ACPI code that, on the affected systems made
process statistics unreliable on SMP kernels.  With the tick infrastructure
focusing all the splintered timer implementations this problem got
propagated to UP kernels too which either had the APIC enabled by the BIOS,
or used the 'lapic' boot option.  Thus the existing regression got visible
on previously working configs too.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@muc.de>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 drivers/acpi/processor_idle.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff -puN drivers/acpi/processor_idle.c~acpi-keep-track-of-timer-broadcasting-fix drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~acpi-keep-track-of-timer-broadcasting-fix
+++ a/drivers/acpi/processor_idle.c
@@ -253,8 +253,10 @@ static void acpi_cstate_enter(struct acp
 #ifdef ARCH_APICTIMER_STOPS_ON_C3
 
 /*
- * Some BIOS implementations switch to C3 in the published C2 state. This seems
- * to be a common problem on AMD boxen.
+ * Some BIOS implementations switch to C3 in the published C2 state.
+ * This seems to be a common problem on AMD boxen, but other vendors
+ * are affected too. We pick the most conservative approach: we assume
+ * that the local APIC stops in both C2 and C3.
  */
 static void acpi_timer_check_state(int state, struct acpi_processor *pr,
 				   struct acpi_processor_cx *cx)
@@ -268,11 +270,8 @@ static void acpi_timer_check_state(int s
 	if (pwr->timer_broadcast_on_state < state)
 		return;
 
-	if(cx->type == ACPI_STATE_C3 ||
-	   boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+	if (cx->type >= ACPI_STATE_C2)
 		pr->power.timer_broadcast_on_state = state;
-		return;
-	}
 }
 
 static void acpi_propagate_timer_broadcast(struct acpi_processor *pr)
_

Patches currently in -mm which might be from mingo@elte.hu are

origin.patch
add-install_special_mapping.patch
i386-vdso-use-install_special_mapping.patch
x86_64-ia32-vdso-use-install_special_mapping.patch
powerpc-vdso-use-install_special_mapping.patch
use-correct-macros-in-raid-code-not-raw-asm.patch
use-correct-macros-in-raid-code-not-raw-asm-include.patch
acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi.patch
sata_sis-build-fix.patch
fix-for-crash-in-adummy_init.patch
bugfixes-pci-devices-get-assigned-redundant-irqs.patch
fix-x86_64-mm-convert-i386-pda-code-to-use-%fs.patch
x86_64-do-not-enable-the-nmi-watchdog-by-default.patch
spin_lock_irq-enable-interrupts-while-spinning-preparatory-patch.patch
spin_lock_irq-enable-interrupts-while-spinning-x86_64-implementation.patch
spin_lock_irq-enable-interrupts-while-spinning-i386-implementation.patch
spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix.patch
spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix-fix.patch
i386-kwatch-kernel-watchpoints-using-cpu-debug-registers.patch
i386-kwatch-kernel-watchpoints-using-cpu-debug-registers-fix.patch
cpuset-remove-sched-domain-hooks-from-cpusets.patch
lockdep-also-check-for-freed-locks-in-kmem_cache_free.patch
lockdep-more-unlock-on-error-fixes.patch
lockdep-more-unlock-on-error-fixes-fix.patch
lockdep-add-graph-depth-information-to-proc-lockdep.patch
consolidate-default-sched_clock.patch
use-cycle_t-instead-of-u64-in-struct-time_interpolator.patch
proc-remove-useless-and-buggy-nlink-settings.patch
simplify-the-stacktrace-code.patch
audit-fix-audit_filter_user_rules-initialization-bug.patch
remove-references-to-obsolete-kernel-config-option-debug_rwsems.patch
order-of-lockdep-off-on-in-vprintk-should-be-changed.patch
minimize-lockdep_on-off-side-effect.patch
fix-apparent-typo-config_lockdep_debug.patch
add-irq-flag-to-disable-balancing-for-an-interrupt.patch
add-a-functions-to-handle-interrupt-affinity-setting.patch
add-a-functions-to-handle-interrupt-affinity-setting-alpha-fix.patch
hz-free-ntp.patch
uninline-jiffiesh-functions.patch
fix-multiple-conversion-bugs-in-msecs_to_jiffies.patch
fix-timeout-overflow-with-jiffies.patch
gtod-persistent-clock-support.patch
i386-use-gtod-persistent-clock-support.patch
i386-remove-useless-code-in-tscc.patch
simplify-the-registration-of-clocksources.patch
x86-rewrite-smp-tsc-sync-code.patch
clocksource-replace-is_continuous-by-a-flag-field.patch
clocksource-replace-is_continuous-by-a-flag-field-fix.patch
clocksource-fixup-is_continous-changes-on-arm.patch
clocksource-fixup-is_continous-changes-on-avr32.patch
clocksource-fixup-is_continous-changes-on-s390.patch
clocksource-fixup-is_continous-changes-on-mips.patch
clocksource-remove-the-update-callback.patch
clocksource-add-verification-watchdog-helper.patch
clocksource-add-verification-watchdog-helper-fix.patch
clocksource-add-verification-watchdog-helper-fix-2.patch
clocksource-add-verification-watchdog-helper-fix-3.patch
mark-tsc-on-geodelx-reliable.patch
uninline-irq_enter.patch
fix-cascade-lookup-of-next_timer_interrupt.patch
extend-next_timer_interrupt-to-use-a-reference-jiffie.patch
hrtimers-namespace-and-enum-cleanup.patch
hrtimers-namespace-and-enum-cleanup-vs-git-input.patch
hrtimers-cleanup-locking.patch
hrtimers-add-state-tracking.patch
hrtimers-clean-up-callback-tracking.patch
hrtimers-move-and-add-documentation.patch
acpi-fix-missing-include-for-up.patch
acpi-keep-track-of-timer-broadcasting.patch
acpi-keep-track-of-timer-broadcasting-fix.patch
allow-early-access-to-the-power-management-timer.patch
i386-apic-clean-up-the-apic-code.patch
clockevents-add-core-functionality.patch
tick-management-core-functionality.patch
tick-management-broadcast-functionality.patch
tick-management-dyntick--highres-functionality.patch
tick-management-dyntick--highres-functionality-fix.patch
clockevents-i383-drivers.patch
clockevents-i383-drivers-fix.patch
i386-rework-local-apic-timer-calibration.patch
i386-prepare-for-dyntick.patch
i386-prepare-nmi-watchdog-for-dynticks.patch
i386-enable-dynticks-in-kconfig.patch
hrtimers-add-high-resolution-timer-support.patch
hrtimers-prevent-possible-itimer-dos.patch
add-debugging-feature-proc-timer_stat.patch
add-debugging-feature-proc-timer_list.patch
add-sysrq-q-to-print-timer_list-debug-info.patch
hrt-dynticks-hotplug-fix.patch
hrt-dynticks-hotplug-fix-fix.patch
generic-vsyscall-gtod-support-for-generic_time.patch
generic-vsyscall-gtod-support-for-generic_time-tidy.patch
time-x86_64-hpet_address-cleanup.patch
revert-x86_64-mm-ignore-long-smi-interrupts-in-clock-calibration.patch
time-x86_64-split-x86_64-kernel-timec-up.patch
time-x86_64-split-x86_64-kernel-timec-up-tidy.patch
time-x86_64-split-x86_64-kernel-timec-up-fix.patch
reapply-x86_64-mm-ignore-long-smi-interrupts-in-clock-calibration.patch
time-x86_64-convert-x86_64-to-use-generic_time.patch
time-x86_64-convert-x86_64-to-use-generic_time-fix.patch
time-x86_64-convert-x86_64-to-use-generic_time-tidy.patch
time-x86_64-hpet-fixup-clocksource-changes.patch
time-x86_64-tsc-fixup-clocksource-changes.patch
time-x86_64-re-enable-vsyscall-support-for-x86_64.patch
time-x86_64-re-enable-vsyscall-support-for-x86_64-tidy.patch
schedule_on_each_cpu-use-preempt_disable.patch
fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch
fsaio-rename-__lock_page-to-lock_page_blocking.patch
fsaio-interfaces-to-initialize-and-to-test-a-wait-bit-key.patch
fsaio-add-a-default-io-wait-bit-field-in-task-struct.patch
fsaio-enable-wait-bit-based-filtered-wakeups-to-work-for-aio.patch
fsaio-enable-asynchronous-wait-page-and-lock-page.patch
fsaio-filesystem-aio-read.patch
fsaio-aio-o_sync-filesystem-write.patch
aio-is-unlikely.patch
sched-avoid-div-in-rebalance_tick.patch
mm-only-sched-add-a-few-scheduler-event-counters.patch
sched-add-above-background-load-function.patch
mm-implement-swap-prefetching.patch
mm-implement-swap-prefetching-use-ctl_unnumbered.patch
sched-cleanup-remove-task_t-convert-to-struct-task_struct-prefetch.patch
scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch
scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch
scheduled-removal-of-sa_xxx-interrupt-flags.patch
detect-atomic-counter-underflows.patch
debug-shared-irqs.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
vdso-print-fatal-signals.patch
vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch
vdso-print-fatal-signals-use-ctl_unnumbered.patch
lockdep-show-held-locks-when-showing-a-stackdump.patch
lockdep-show-held-locks-when-showing-a-stackdump-fix.patch
lockdep-show-held-locks-when-showing-a-stackdump-fix-2.patch
kmap_atomic-debugging.patch

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Len Brown]

On Monday 29 January 2007 01:55, Ingo Molnar wrote:
> 
> * Len Brown <lenb@kernel.org> wrote:
> 
> > > -     if(cx->type == ACPI_STATE_C3 ||
> > > -        boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> > > +	if (cx->type >= ACPI_STATE_C2)
> > >  		pr->power.timer_broadcast_on_state = state;
> > > -		return;
> > > -	}
> > 
> > This is going to be a problem. Do you have a pointer to an Intel box 
> > who's LAPIC timer stops in C2?
> 
> btw., why is it going to be a problem? It basically activates the 
> fall-back-to-PIT-broadcasting workaround for all C2-capable systems. 
> Given that most modern laptops do C3, and C3 definitely turns off the 
> lapic, is this a big issue? I'd rather default to the more conservative 
> behavior on C2 too.

Why don't we activate the fall-back-to-PIT-broadcasting always --
even for systems which have just C1?

The answer to that question is the same as the answer to the question you ask.

I don't think the above patch is conservative, AFAIK it is simply erroneous.

My understanding is that
1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
2. All existing Intel systems have a BROKEN LAPIC timer in C3.

If you've found a system that defies these rules, then I'm extremely
interested to know about it.

> note that with the new clockevents code the workaround can fall back not 
> just to the PIT but to hpet as well - if it's available. The T60 
> core2duo laptop i have does that for example. That gives much 
> higher-quality dynticks behavior. (the PIT is limited to a maximum of 27 
> msecs interval - resulting in a minimum rate of 37 timer irqs per 
> second)

The fact that the HPET can interrupt at a very high rate is moot
from a power management point of view.
If we are focusing on the region above O(40H) HZ, then we already
blew it from a power savings point of view, as the very deep C-states
will not save any power at high interrupt rates.

Another alternative would be for systems with C3 to fall-back to a
periodic tick scheme that we have today.  From a power point of view,
HZ=100 would be only a little bit worse than Windows HZ=64.
However, FC6 seems to have marched off an built with
HZ=1000 -- so we'd have some challenges with static HZ too...

-Len

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Thomas Gleixner]

On Mon, 2007-01-29 at 18:55 -0500, Len Brown wrote:
> My understanding is that
> 1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
> 2. All existing Intel systems have a BROKEN LAPIC timer in C3.
> 
> If you've found a system that defies these rules, then I'm extremely
> interested to know about it.

Ask akpm. His vaio has this problem since ages. As well as other Intel
based boxen. Yes, they have broken BIOSes ....

Adding a commandline option like "c2works" might be appropriate. This
would also keep TSC alive on C2, where we default to not use it when C2
is reached right now for the very same reason (break as few boxen as
possible). Say thanks to AMD for that invention.

> > note that with the new clockevents code the workaround can fall back not 
> > just to the PIT but to hpet as well - if it's available. The T60 
> > core2duo laptop i have does that for example. That gives much 
> > higher-quality dynticks behavior. (the PIT is limited to a maximum of 27 
> > msecs interval - resulting in a minimum rate of 37 timer irqs per 
> > second)
> 
> The fact that the HPET can interrupt at a very high rate is moot
> from a power management point of view.
> If we are focusing on the region above O(40H) HZ, then we already
> blew it from a power savings point of view, as the very deep C-states
> will not save any power at high interrupt rates.

You misunderstood. HPET is much better than PIT for dynticks, as the
maximum timeout with HPET is way longer than with PIT (PIT maximum is
27ms). We can idle sleep longer with HPET than with PIT.

> Another alternative would be for systems with C3 to fall-back to a
> periodic tick scheme that we have today.  From a power point of view,
> HZ=100 would be only a little bit worse than Windows HZ=64.
> However, FC6 seems to have marched off an built with
> HZ=1000 -- so we'd have some challenges with static HZ too...

With dyntick enabled kernels you get ~ HZ=37 as the worst case with PIT,
while we go down to ~4HZ with HPET / apic timer (as long as it works)

	tglx

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Mon, 2007-01-29 at 18:55 -0500, Len Brown wrote:
> > My understanding is that
> > 1. All existing and future Intel systems have a FUNCTIONAL LAPIC timer in C2.
> > 2. All existing Intel systems have a BROKEN LAPIC timer in C3.
> > 
> > If you've found a system that defies these rules, then I'm extremely
> > interested to know about it.
> 
> Ask akpm. His vaio has this problem since ages. As well as other Intel 
> based boxen. Yes, they have broken BIOSes ....

my HP nx9030 is one such box too. [ I sent the BIOS info - Len, did you 
get those? ]

	Ingo

Re: + acpi-keep-track-of-timer-broadcasting-fix.patch added to -mm tree

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> > Another alternative would be for systems with C3 to fall-back to a
> > periodic tick scheme that we have today.  From a power point of view,
> > HZ=100 would be only a little bit worse than Windows HZ=64.
> > However, FC6 seems to have marched off an built with
> > HZ=1000 -- so we'd have some challenges with static HZ too...
> 
> With dyntick enabled kernels you get ~ HZ=37 as the worst case with 
> PIT, while we go down to ~4HZ with HPET / apic timer (as long as it 
> works)

s/worst case/best case

the lower we can make the timer irq rate on an idle system, the better. 
HPET allows us to go from 37 Hz down to 4 Hz.

	Ingo