[Top] [All Lists]

Re: Route cache performance

To: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Subject: Re: Route cache performance
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 16 Sep 2005 21:57:31 +0200
Cc: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, Simon Kirby <sim@xxxxxxxxxxxxx>, Eric Dumazet <dada1@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20050916190404.GA11012@xxxxxxxxxxxxxxx>
References: <17167.29239.469711.847951@xxxxxxxxxxxx> <20050906235700.GA31820@xxxxxxxxxxxxx> <17182.64751.340488.996748@xxxxxxxxxxxx> <20050907162854.GB24735@xxxxxxxxxxxxx> <20050907195911.GA8382@xxxxxxxxxxxxxxx> <20050913221448.GD15704@xxxxxxxxxxxxx> <20050915210432.GD28925@xxxxxxxxxxxxxxx> <17193.59406.200787.819069@xxxxxxxxxxxx> <20050915222102.GA30387@xxxxxxxxxxxxxxx> <17194.47097.607795.141059@xxxxxxxxxxxx> <20050916190404.GA11012@xxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
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.


<Prev in Thread] Current Thread [Next in Thread>