Re: Awfully slow /proc/net/tcp, netstat, in.identd in 2.4 (updated)

[Benjamin LaHaise <bcrl@redhat.com>]

On Fri, Oct 19, 2001 at 02:56:39PM -0700, David S. Miller wrote:
> It doesn't need to "fit in the cache" to perform optimally, that's
> a load of crap Ben.
> 
> I actually tested this, and in fact on a cpu that has a meager 512K
> cache at the time, and it did turn out to be more important to keep
> the hash chains short than to keep it fitting in the cache.
> 
> So please don't give me any crap about "fitting in the cache" unless
> you can show me hard numbers that show that it does in fact perform
> worse.

Okay, let's take a look at the case where I have 64 connections open: if 
I'm using a 64 entry hash table with one 4 byte pointer per entry and 
perfect hashing, then it has a cache footprint of 256 bytes.  Max.  Now, 
the same hash table blown up to 4MB is going to have a cache footprint 
of 64 bytes (1 cache line) per entry, for a total of a 4KB cache footprint.
Which is better?

> Let me clue you in.  If the hash chains get long, you (instead of
> cache missing on the table itself) are missing the cache several
> times over walking the long hash chains.

Don't AssUMe that I don't realise this.  What I'm saying is that a 4MB hash 
table for a system with a puny number of connections is bloat.  Needless 
bloat.  4MB is enough memory for a copy of gcc.  Or enough to run 4 shells.  
If the hash table was grown dynamically, I wouldn't have this complaint.

		-ben