Le 03/11/2016 à 17:31, Florian Westphal a écrit : > Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx> wrote: >>> Change since v1: use system_long_wq instead of normal system wq (suggested by >>> Eric Dumazet). >>> >>> Nicholas is currently away; I would like to get his feedback on this one >>> before it gets applied. >> Thank you for the update. >> With that patch, some events still have a delay > 2 minutes, which I think is >> too much. > > Too bad, in my tests it was < 1 minute. > >> If I'm not wrong, the worst delay with this patch is: >> 10 (GC_INTERVAL_MAX) + 0,001 + 5,001 + 5,002 + 5,003 + ... + 6,024 (= 5 secs + >> 1024 mecs) > > Worst case is over 3 hours (assuming no eviction happened at all and we > have one stale entry that needs the full scan). 3 hours to get a netlink event is really no acceptable ;-) > >> Previously (in private discussions), you propose a algorithm which guarantee a >> full table scan in a predefined delay. A "good" solution may have such guarantee. > > Now that this uses system_long_wq prolonged a long scan time might not > be that bad anymore, so we might consider lowering the divisor and/or the > max interval. > > However, I will not send a new iteration of this change since I don't > know how to test this. Its easy to make the delay low, but it will come > at additonal cpu cost. I have no idea where to make the tradeoff. For me, the priority is to deliver events with a reasonnable delay (and I think Pablo also asks for this in a previous email). I understand that the cpu cost need to be taken into account, but it's a tradeoff of the new design I think. Regards, Nicolas -- 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
