Re: route cache DoS testing and softirqs

[Andrea Arcangeli]

On Thu, Apr 01, 2004 at 12:36:00AM +0200, Robert Olsson wrote:
> 
> Andrea Arcangeli writes:
> 
>  > Maybe the problem is simply that NAPI should be tuned more aggressively,
>  > it may have to poll for a longer time before giving up.
> 
>  It cannot poll much more... 20 Million packets were injected in total
>  there were 250 RX irq's. Most from my ssh sessions. There are some TX 
>  interrupts... it's another story

I didn't focus much on the irq count, but now that I look at it, it
looks like the biggest source of softirq in irq context is the timer
irq, not the network irq. That explains the problem and why NAPI
couldn't avoid the softirq load in irq context, NAPI avoids the network
irqs, but the softirqs keeps running in irq context.

So lowering HZ to 100 should mitigate the problem significantly.

But I feel like we should change the softirq code so that the irqexit
runs only the softirq setup by the current (or nested) irq handler. This
way the timer irq will stop executing the softirqs posted by the network
stack and it may very well fix the problem completely. This definitely
will help fairness too.

>  Packet flooding is just our way to generate load and kernel locking must 
>  work with and without irq's. As far as I understand the real problem is 
>  when do_softirq is run from irqexit etc.

yes, but it's run from the _timer_ irq as far as I can tell.  Changing
the softirq code so that the irqexit only processes softirqs posted in
the irq handlers should fix it.

>  If we tag the different do_softirq sources (look in my testpatch) we can 
>  control the softirqs better. For example; do_softirq's from irqexit etc 
>  could be given low a "max_restart" this to move processing to ksoftird 
>  maybe even dynamic.

max_restart is needed exactly to avoid irqexit load to be offloaded to
regular kernel context, so that's basically saying that we should
disable max_restart but that's not a good solution for some non-NAPI
workload.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/