Date: Tue, 27 May 2003 15:04:49 -0700 (PDT)
Message-Id: <20030527.150449.08322270.davem@redhat.com>
To: andrea@suse.de
Cc: akpm@digeo.com, davidsen@tmr.com, haveblue@us.ibm.com, habanero@us.ibm.com,
       mbligh@aracnet.com, linux-kernel@vger.kernel.org
Subject: Re: userspace irq balancer
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <20030527115314.GU3767@dualathlon.random>
References: <20030527012617.GH3767@dualathlon.random>
	<20030526.231120.26504389.davem@redhat.com>
	<20030527115314.GU3767@dualathlon.random>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1728
Lines: 36

   From: Andrea Arcangeli <andrea@suse.de>
   Date: Tue, 27 May 2003 13:53:14 +0200

   in case it wasn't obvious (that is the whole point of ksoftirqd) what
   accomplishes in a single word is "fairness" and "not starving userspace
   during networking".

The problem is that is gives up and goes to ksoftirqd far too easily.

Also, if a softirq is triggered between when we wake up ksoftirqd and
ksoftirqd actually runs, we just run the loop again in do_softirq().

This situation is even more likely if we are being "softirq bombed".
In fact in such a situation it is almost a certainty that do_softirq()
will execute multiple times before we schedule to any task.

In fact, and here is the important part, we probably won't run very
much userspace at all if we are being "softirq bombed".  Every trap,
softirq causing or not, is going to cause us to drop into do_softirq()
again and again and again.

Perhaps even, we will drain the pending softirqs before ksoftirqd even
gets to execute.  In this case the ksoftirqd wakeup and context switch
is a total waste of cpu cycles.

You are trying to apply flow control in an odd way to softirqs.
But the problem with such schemes is that they absolutely do not
make the problem go away.  You are merely moving the work from one
place to another, and in many cases added more useless work.  The one
thing you don't do when you are resource limited is take more of those
resources away and that is exactly what the ksoftirqd scheme does.
-
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/