Messages in this thread | | | Date | Wed, 31 Mar 2004 02:36:48 +0530 | From | Dipankar Sarma <> | Subject | Re: route cache DoS testing and softirqs |
| |
On Tue, Mar 30, 2004 at 10:47:32PM +0200, Andrea Arcangeli wrote: > I see what's going on now, yes my patch cannot help. the workload is > simply generating too much hardirq load, and it's like if we don't use > softirq at all but that we process the packet inside the hardirq for > this matter. As far as RCU is concerned it's like if there a no softirq > at all but that we process everything in the hardirq. > > so what you're looking after is a new feature then: > > 1) rate limit the hardirqs > 2) rate limit only part of the irq load (i.e. the softirq, that's handy > since it's already splitted out) to scheduler-aware context (not > inside irq context anymore)
There were a number of somewhat ugly softirq limiting patches that Robert tried out (not spitting them to scheduler-aware context) and some combination of that worked well in Robert's setup. I will see if I can revive that. That said, we would need to find out how badly we affect network performance with that thing.
> 3) stop processing packets in irqs in the first place (NAPI or similar) > > however I start to think they can be all wrong, and that rcu is simply > not suitable for purerely irq usages like this. w/o rcu there would be > no need of the scheduler keeping up with the irq load, and in some usage > I can imagine that it is a feature to prioritize heavily on the > irq load vs scheduler-aware context.
Not necessarily, we can do a call_rcu_bh() just for softirqs with softirq handler completion as a quiescent state. That will likely help with the route cache overflow problem atleast.
Thanks Dipankar - 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/
| |