Messages in this thread | | | Date | Tue, 30 Mar 2004 23:27:35 +0200 | From | Andrea Arcangeli <> | Subject | Re: route cache DoS testing and softirqs |
| |
On Wed, Mar 31, 2004 at 02:36:48AM +0530, Dipankar Sarma wrote: > 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.
cute, I like this. You're right all we care about is a quiscient point against softirq context (this should work fine against regular kernel context under local_bh_disable too). This really sounds a smart and optimal and finegriend solution to me. The only thing I'm concerned about is if it slowdown further the fast paths, but I can imagine that you can implement it purerly with tasklets and no change to the fast paths (I mean, I wouldn't enjoy further instrumentations like the stuff you had to add to the scheduler especially in the preempt case). I mean, you've just to run 1 magic takklet per cpu then you declare the quiscient point. The only annoyance will be the queueing of these tasklets in every cpu, that may need IPIs or some nasty locking. Of course we should use the higher prio tasklets, so they run before the other softirqs.
Is this the suggestion from Alexey or did he suggest something else? the details of his suggestion weren't clear to me.
after call_rcu_bh everything else w.r.t. softirq/scheduler will return low prio. I mean, the everything else will return a "irq load (hardirq+softirq) runs on top of kernel context and they're not accounted by the scheduler" like it has always been in the last thousand kernel releases ;) that may need solving eventually, but still the routing cache sounds optimal with the call_rcu_bh. - 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/
| |