Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 1 Oct 2001 18:38:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 1 Oct 2001 18:38:10 -0400 Received: from h24-64-71-161.cg.shawcable.net ([24.64.71.161]:50683 "EHLO webber.adilger.int") by vger.kernel.org with ESMTP id ; Mon, 1 Oct 2001 18:37:49 -0400 From: Andreas Dilger Date: Mon, 1 Oct 2001 16:36:31 -0600 To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Alan Cox , Alexey Kuznetsov , Andrea Arcangeli , Simon Kirby Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5 Message-ID: <20011001163631.C23808@turbolinux.com> Mail-Followup-To: Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds , Alan Cox , Alexey Kuznetsov , Andrea Arcangeli , Simon Kirby In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Oct 02, 2001 00:16 +0200, Ingo Molnar wrote: > - the irq handling code has been extended to support 'soft mitigation', > ie. to mitigate the rate of hardware interrupts, without support from > the actual hardware. There is a reasonable default, but the value can > also be decreased/increased on a per-irq basis via /proc/irq/NR/max_rate. > > the method is the following. We count the number of interrupts serviced, > and if within a jiffy there are more than max_rate interrupts, the code > disables the IRQ source and marks it as IRQ_MITIGATED. On the next timer > interrupt the irq_rate_check() function is called, which makes sure that > 'blocked' irqs are restarted & handled properly. How far is it to go from a mitigated IRQ (because of too high an interrupt rate) to a polled interface (e.g. for network cards)? This was discussed a number of times to improve overall performance on bust network systems. Concievably, a network card could tune max_rate to a value where it is more efficient (CPU wise) to poll the interface instead of using IRQs. However, waiting for the next regular timer interrupt may be too long (resulting in lost packets) as buffers overflowed. Would it also be possible for a driver to register a "maximum delay" between servicing interrupts (within reason, on a non-RT system) so that it can say "I have X kB of buffers, and the maximum line rate is Y kB/s, so I need to be serviced within X/Y s when polling without losing data". Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/