David Miller writes:
Interesting.
> Actually, more accurately, the conflict exists in how this GC
> logic is implemented. The core issue is that hash table size
> guides the GC processing, and hash table growth therefore
> modifies those GC goals. So with the patch below we'll just
> keep growing the hash table instead of giving GC some time to
> try to keep the working set in equilibrium before doing the
> hash grow.
AFIK the equilibrium is resizing function as well but using fixed
hash table. So can we do without equilibrium resizing if tables
are dynamic? I think so....
With the hash data structure we could monitor the average chain
length or just size and resize hash after that.
> One idea is to put the hash grow check in the garbage collector,
> and put the hash shrink check in rt_del().
>
> In fact, it would be a good time to perhaps hack up some entirely
> new passive GC logic for the routing cache.
Could be, remeber GC in the hash chain also which was added after
although it does's decrease the number of entries but it gives
an upper limit. Also gc-goal must picked so it does not force
unwanted resizing.
> BTW, another thing that plays into this is that Robert's TRASH work
> could make this patch not necessary :-)
It has "built-in" resize and chain control and the gc-goal is chosen not
to unnecessary resize the root node.
Cheers.
--ro
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
