Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 15 Mar 2002 03:55:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 15 Mar 2002 03:55:42 -0500 Received: from mx2.elte.hu ([157.181.151.9]:8379 "HELO mx2.elte.hu") by vger.kernel.org with SMTP id ; Fri, 15 Mar 2002 03:55:23 -0500 Date: Fri, 15 Mar 2002 08:50:43 +0100 (CET) From: Ingo Molnar Reply-To: mingo@elte.hu To: "Martin J. Bligh" Cc: Martin Wilck , , Linux Kernel mailing list Subject: Re: Severe IRQ problems on Foster (P4 Xeon) system In-Reply-To: <41140000.1016130154@flay> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Mar 2002, Martin J. Bligh wrote: > >> Btw is it correct that one could also use the APIC Task Priority Registers > >> to implement "fair" IRQ routing? (If linux adjusted them, which it > >> currently doesn't). > > > > Yes, and Dave Olien has already done this. It's a good idea for P3, > > and seems to me to be essential for P4. another problem with TPR-based IRQ routing (in addition to the ones i mentioned in the previous mail) is that if you 'deny' certain IRQs via the TPR, then if all CPUs run kernel-intensive jobs, then IRQs will never be served by any of the CPUs (or will be served only after a long latency). Sure, this can be hacked around, but if gets ugly very fast and doesnt get us very far. All in one, i found the TPR to be not flexible enough for what we really want: good IRQ distribution and good IRQ affinity at once. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/