Alexey Kuznetsov writes:
> Most likely, something is broken in the e1000 driver. Otherwise, no ideas.
No it's hard to guess. Simon will hopefully bring some more data.
> I do not see _why_. Apparently some overhead is present but I do not
> understand why it is so large. Is it just because 300 redundant entries
> pollute cache a little more? I do not see another reasons.
Yes when RX softirq is done. RCU tasklet has to take over and probably
reload cache with some the entries to complete the deletion. It might be
worth a profile...
> Maybe it makes sense to compare this effect with the effect of increment
> gc_elasticity by 1. If it is due to cache pollution, effect of increment
> of gc_elasticity, which increses size of cache by rhash_size should be
> even worse.
Something like that yes :) but if we increase gc_elasticity we also add
more spinning in hash chains. So we need to sort out if the expected
performance drop comes from extra hash spinning or are cache effects from
the increased hash.