Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S276671AbRJGUiH>; Sun, 7 Oct 2001 16:38:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S276673AbRJGUh5>; Sun, 7 Oct 2001 16:37:57 -0400
Received: from [195.223.140.107] ([195.223.140.107]:25076 "EHLO athlon.random")
	by vger.kernel.org with ESMTP id <S276671AbRJGUh4>;
	Sun, 7 Oct 2001 16:37:56 -0400
Date: Sun, 7 Oct 2001 22:37:15 +0200
From: Andrea Arcangeli <andrea@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: BALBIR SINGH <balbir.singh@wipro.com>,
        Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5
Message-ID: <20011007223715.H726@athlon.random>
In-Reply-To: <3BBC30B6.1030203@wipro.com> <Pine.LNX.4.33.0110041221330.6256-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0110041221330.6256-100000@localhost.localdomain>; from mingo@elte.hu on Thu, Oct 04, 2001 at 12:25:13PM +0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ingo could you explain me one basic thing?

What the hell has the hardirq rate limit logic to do with softirqs?

(btw, I don't know why you call it irq-rewrite, you didn't rewrote
anything, you just added a irq flood avoidance feature by lefting irq
disabled when you detect an irq flood caming in)

hardirqs have nothing to do with softirqs. Softirq as their name suggest
are a totally software thing, they're generated by software,
incidentally for the network stack they're posted from hard irq handlers
because network cards are irq driven, but that's just a special case (of
course it is the common case), but it is not the general case.

Your hardirq rate limit logic that lefts the irq disabled for some time
is certainly needed from a security standpoint to avoid DoS if untrusted
users can generates a flood of irqs using some device, unless the
devices provides a way to flow control the irq rate (which I understood
most hardware that can generate a flood of irqs provides anyways).

as far I can tell any change to the softirq logic is completly
orthogonal with the softirq changes. Changing both things together or
seeing any connection between the two just shows a very limited network
oriented view of the whole picture about the softirqs.

Now I'm not saying that I don't want to change anything in the softirq
logic, for example the deschedule logic made lots of sense and I can see
the benefit for users like the network stack.

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