On Mon, Feb 23, 2015 at 09:03:58PM +0000, Thomas Graf wrote: > On 02/23/15 at 11:12am, josh@xxxxxxxxxxxxxxxx wrote: > > In theory, resizes should only take the locks for the buckets they're > > currently unzipping, and adds should take those same locks. Neither one > > should take a whole-table lock, other than resize excluding concurrent > > resizes. Is that still insufficient? > > Correct, this is what happens. The problem is basically that > if we insert from atomic context we cannot slow down inserts > and the table may not grow quickly enough. > > > Yeah, the add/remove statistics used for tracking would need some > > special handling to avoid being a table-wide bottleneck. > > Daniel is working on a patch to do per-cpu element counting > with a batched update cycle. One approach is simply to count only when a resize operation is in flight. Another is to keep a per-bucket count, which can be summed at the beginning of the next resize operation. Thanx, Paul -- 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
