Re: [patch] softirq-2.4.10-B2

[Simon Kirby]

On Fri, Sep 28, 2001 at 09:18:17AM +0200, Ingo Molnar wrote:

> basically the problem is that there is a big 'gap' between the activation
> of softirqs, and the time when ksoftirqd starts running. There are a
> number of mechanisms within the networking stack that are quite
> timing-sensitive. And generally, if there is work A and work B that are
> related, and we've executed work A (the hardware interrupt), then it's
> almost always the best idea to execute work B as soon as possible. Any
> 'delaying' of work B should only be done for non-performance reasons:
> eg. fairness in this case. Now it's MAX_SOFTIRQ_RESTART that balances
> performance against fairness. (in most kernel subsystems we almost always
> give preference to performance over fairness - without ignoring fairness
> of course.)

This may be somewhat related to something I've been thinking about
lately: The fact that most machines will choke under a simple UDP
while(1) sendto() attack (eg: around 100Mbit wire speed with lots of small
packets).  It seems that what's happening is a new packet comes in
immediately after the last interrupt is serviced (because the packets are
so small), so the CPU has no time to execute anything else and goes right
back into the interrupt handler.  This starves userspace CPU time.

Would your changes affect this at all?  It would be nice if this could
somehow be batched so that a Linux router could be capable of handling
large amounts of traffic with small packets, and wouldn't choke when lots
of small packets (most commonly from a TCP SYN bomb) go through it.

Actually, I just tested my while(1) sendto() UDP spamming program on an
Acenic card and noticed that it seems to do some sort of batching /
grouping, because the number of interrupts reported by vmstat is only
8,000 while it's easily 75,000 on other eepro100 boxes.  Interesting...

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[       [e-mail]       ][       [e-mail]        ]
[ Opinions expressed are not necessarily those of my employers. ]