From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755663AbYESOvQ (ORCPT ); Mon, 19 May 2008 10:51:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751478AbYESOvA (ORCPT ); Mon, 19 May 2008 10:51:00 -0400 Received: from one.firstfloor.org ([213.235.205.2]:40220 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbYESOvA (ORCPT ); Mon, 19 May 2008 10:51:00 -0400 Message-ID: <483193B3.3090807@firstfloor.org> Date: Mon, 19 May 2008 16:50:27 +0200 From: Andi Kleen User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ingo Molnar , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] I/O APIC: Timer through 8259A revamp References: <87hccubgni.fsf@basil.nowhere.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. > 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) > The use of the local APIC timer as a replacement was recommended back > then, That was before CPU power saving was invented I guess @) > 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, -Andi