[RFC][PATCH 0/3]i386,x86-64 Handle missing local APIC timer interrupts on C3 state

From: Venkatesh Pallipadi
Date: Thu Dec 08 2005 - 21:13:39 EST



Sorry about the duplicate. Had an incomplete subject line in the earlier mail.

Thanks,
Venki

Problem:
Processor C3 state and beyond will shut down the local APIC timer
on variety of Intel processors. This will be a issue on systems with more than
one logical CPUs, as these systems depend on local APIC timer and timer
interrupt for scheduling (idle_balance/busy_balance) and process accounting
purposes.
One of the side-effects of this is, the idle time reported for a CPU can be less
than the actual time is spends idling. As a result of this wrong idle time
being reported, ondemand governor and other similar programs that depend on
the idle statistics may get misled. ondemand governor will think system is
less idle than it really is and will increase the CPU frequency unnecessarily,
for example.

Solution:
After my failed attempt earlier
(http://www.ussg.iu.edu/hypermail/linux/kernel/0504.3/1640.html),
I am back with another attempt.

The basic idea is to use the external timer interrupt and have one CPU broadcast
it to all the other C3 capable CPUs through an IPI. The C3 capable CPUs will
disable local APIC timer. Note that C3 capability on a CPU can appear/disappear
during run-time. So, whether a CPU uses local APIC or timer interrupt broadcast
can change at run time. But, once a CPU is detected as C3 capable we start using
the broadcast mode (even when CPU is not really in C3).

This patch should be a noop on systems that does not support C3.

The patch is split into 3 parts
* remove sub-jiffy control in local APIC timer.
* i386 apic changes to switch from APIC timer to broadcast timer
* x86_64 apic changes to switch from APIC timer to broadcast timer

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx>

Comments?

Thanks,
Venki


-
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/