Messages in this thread | | | Date | Thu, 1 Apr 2004 02:16:11 +0530 | From | Dipankar Sarma <> | Subject | Re: route cache DoS testing and softirqs |
| |
On Wed, Mar 31, 2004 at 12:49:02AM +0200, Andrea Arcangeli wrote: > On Tue, Mar 30, 2004 at 02:22:10PM -0800, David S. Miller wrote: > > Otherwise, keep in mind what I said, and also as Robert mentioned every > > single local_bh_enable() is going to call do_softirq() if the count falls > > to zero. > > I was less concerned about the do_sofitrq in local_bh_enable, since that > runs in a scheduler-aware context, so at least the timeslice is > definitely accounted for and it'll schedule at some point (unlike with > an hardirq flood). Actually the length of the default timeslice matters > too here, lowering the max timeslice to 10msec would certainly reduce > the effect.
That is there in my list of things to test.
> call_rcu_bh will fix the local_bh_enable too. The only problem with > call_rcu_bh is how to queue the tasklets in every cpu (an IPI sounds > overkill at high frequency, because effectively here we're running the rcu > callbacks in a potential fast path). OTOH if we've to add a spinlock to > queue the tasklet, then we might as well take a spinlock in the routing > cache in the first place (at least for this workload).
I don't do any of this. I just have a separate quiescent state counter for softirq RCU. It is incremented for regular quiescent points like cswitch, userland, idle loop as well as at the completion of each softirq handler. call_rcu_bh() uses its own queues. Everything else works like call_rcu().
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/
| |