Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 3 Oct 2001 12:34:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 3 Oct 2001 12:34:43 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:5899 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Wed, 3 Oct 2001 12:34:27 -0400 Date: Wed, 3 Oct 2001 09:33:12 -0700 (PDT) From: Linus Torvalds To: Ben Greear cc: jamal , Ingo Molnar , , Alexey Kuznetsov , Robert Olsson , Benjamin LaHaise , , Alan Cox Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5 In-Reply-To: <3BBB31F4.C223E12E@candelatech.com> 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 Wed, 3 Oct 2001, Ben Greear wrote: > > Will NAPI patch, as it sits today, fix all IRQ lockup problems for > all drivers (as Ingo's patch claims to do), or will it just fix > drivers (eepro, tulip) that have been integrated with it? Note that the big question here is WHO CARES? There are two issues, and they are independent: (a) handling of network packet flooding nicely (b) handling screaming devices nicely. First off, some comments: (a) is not a major security issue. If you allow untrusted users full 100/1000Mbps access to your internal network, you have _other_ security issues, like packet sniffing etc that are much much MUCH worse. So the packet flooding thing is very much a corner case, and claiming that we have a big problem is silly. HOWEVER, (a) _can_ be a performance issue under benchmark load. Benchmarks (unlike real life) are almost always set up to have full network bandwidth access, and can show this issue. (b) is to a large degree due to a stupid driver interface. I've wanted to change the IRQ handler functions to return a flag mask for about three years, but with hundreds of drivers it's always been a bit too painful. Why do we want to return a flag mask? Because we want the _driver_ to be able to say "shut me up" (if the driver cannot shut itself up and wants to throttle), and we want the _driver_ to be able to say "Hmm, that interrupt was not for me", so that the higher levels can quickly figure out if we have the case of us having two drivers but three devices, and the third device screaming its head off. Ingo tries to fix both of these with a sledgehammer. I'd rather use a bit more finesse, and as I do not actually agree with the people who seem to think that this is a major problem TODAY, I'll be more than happy to have people think about it. The NAPI people have thought about it - but it has obviously not been descussed _nearly_ widely enough. I personally am very nervous about Ingo's approach. I do not believe that it will work well over a wide range of machines, and I suspect that the "tunables" have been tuned for one load and one machine. I would not be surprised if Ingo finds that trying to put the machine under heavy disk load with multiple disk controllers might also cause interrupt mitigation, which would be unacceptably BAD. Linus - 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/