Re: [PATCH] I/O APIC: Timer through 8259A revamp

On Mon, 19 May 2008, Andi Kleen wrote:

With the ACPI tables, hardware is modern enough the timer interrupt
should be directly available, but is usually wired in the way recommended
by the MP spec.

I originally had that assumption too, but in practice that doesn't seem
to be always the case unfortunately. Or sometimes the tests just fail
for whatever reason and they drop into the fallback path.

Well, the fallback path was meant to be used with hardware suffering from
limitations and not from broken configuration tables. If the
configuration recorded in the tables is broken, then who knows what the
hardware looks like? Anything may happen. This should really be the case
for: "Fix your *** firmware!" With Flash memories in wide use today,
there is really no excuse and the technology behind these tables does not
require a rocket scientist.

That is the output of the master 8259A goes to INT0 of
the I/O APIC (or is only connected to local APICs) and the timer is routed
to INT2.

There are already a couple of wiring differences in common chipsets.
Mostly hurts on the fallback path especially when multiple sources are
enabled (then you might end up with duplicated interrupts, happened often
on ATI systems)

As soon as you hit the through-8259A mode chances are you will start
suffering from things like assumptions about the state of the hardware
made by whoever has written SMM code for this system, which may result in
reassertion of the interrupt that has already been handled (the mode of
operation of the 8254 does not help here). Otherwise if the timer
interrupt genuinely arrives through multiple I/O APIC inputs, then we have
a piece of sloppy code somewhere -- we should never have more than one
input at a time with the same interrupt vector enabled; this is also a
grey area of operation of the APIC itself, at least with some
implementations.

The use of the local APIC timer as a replacement was recommended back
then,

That was before CPU power saving was invented I guess @)

Well, the i386SL was *the* power-saving Intel CPU when the i82489DX was
being worked on and certainly back then nobody sane would go through the
pain of putting additional CPUs into a system only to make them go to
sleep. ;-) The SMM had already been committed in that CPU in case you
were asking...

but I think IRQ8 from the RTC was also a good solution,

Trouble on Linux is that RTC doesn't support any of the traditional HZ
values. I considered writing a RTC driver back then, but didn't do
it because of this.

On the other hand with wider use of tickless kernels and hrtimers it might
be tolerable to use non standard HZ,

I don't think the value of HZ should be a problem anymore now that we
have a separate user-visible HZ -- and it's been a while like that. We
have a choice of three values of HZ already and for example the MIPS port
uses the closest powers of two to the usual values of 100, 250 and 1000
where necessary because of the very same reason and I haven't heard about
any problems resulting from that.

Note some systems have the polarity reported incorrectly for the RTC
interrupt -- that can be easily solved, but care has to be taken.

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

Relevant Pages

  • Re: [PATCH 2.6.13-rc5-gitNOW] msleep() cannot be used from interrupt
    ... >>Original old code was busy waiting for 20ms, while on my hardware in the worst ... > It this is called from an interrupt, jiffies will ... > Just spin while rtc is updating some maximum number of loops. ...
    (Linux-Kernel)
  • Re: 2.6.11 timeval_to_jiffies() wrong for ms resolution timers
    ... >> If you really want millisecond accuracy, ... You can make hardware timers with picosecond resolution. ... A CPU takes a variable amount of time to branch when ... a hardware interrupt occurs. ...
    (Linux-Kernel)
  • Re: [PATCH v3] enable x2APIC without interrupt remapping under KVM
    ... decide to deploy to work with real hardware. ... I have been seriously contemplating causing a cpu hot-unplug request ... obviously we need to disassociate any irqs from such a cpu. ... interrupt handler without without risking dropping an interrupt. ...
    (Linux-Kernel)
  • Re: Simple question about CPUs and processes
    ... > is the hardware itself choosing which CPU will execute this ... > But I think it is the OS kernel (FreeBSD in this case) and the SMP ... This is basically the case on hardware supported by FreeBSD: ... to CPUs to attempt to help manage interrupt load. ...
    (freebsd-hackers)
  • Re: F: Interrupt-Logik bei Mikrocontroller/PC-CPU?
    ... ganz kurz zwischen zwei Flanken gesetzt wird dann wird kein Interrupt ... Abfrage geschieht aber durch die Hardware, ... zumindest quasi) asynchron zum CPU Takt erkannt und so lange gespeichert ... bis die CPU die ISR ausfuehrt. ...
    (de.sci.electronics)
Loading