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

Benjamin LaHaise (bcrl@redhat.com)
Fri, 19 Oct 2001 18:04:34 -0400


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/