On Fri, 17 Apr 2009, Peter Zijlstra wrote: > > Since its a full broadcast, we can do that _today_ using on_each_cpu(). > But whatever way we turn this, this will be a very expensive operation. > Imagine doing that on your 256-way for every iptables rules change. Well, you _could_ just have a per-CPU bit of "have I used nf rules since the last update", and skip those CPU's. Use memory ordering to check the bits (set the bit _before_ looking up a NF rule, and check them _after_ doing the update, and have a barrier in between if you really think it matters). Remember: the cost was never about a single filter rule update. The cost of a single one is almost immaterial, as long as it's not in hundreds of milliseconds. It's the cost of people building up things incrementally that caused this thing. So if you have 200 "iptables" commands in a sequence, and especially during bootup, a trivial "has the old rule been ever even looked at on this CPU" would already fix the issue. Because it would always be zero in the only case where it matters. This is, of course, what we do for the TLB flushing issue. We don't want to send IPI's to all CPU's, and in 99.999% of all cases we don't need to, because the other CPU's never even loaded the MM. Linus -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
