Re: [patch 9/11] net: dst_entry.refcount, use, lastuse to use alloc_percpu

From: Ravikiran G Thirumalai <redacted>
Date: Tue, 13 Sep 2005 15:07:37 -0700

Agreed the dst changes are ugly; that can be worked on.  But the
cacheline bouncing problem on the atomic_t dst_entry refcounter has
been around for quite a while -- even on SMPs, not just NUMA.  We
need a solution for that.  I thought you were against the dst_entry
bloat caused by the previous version of the dst patch.  alloc_percpu
takes that away.  You had concerns about workloads with low route
locality. Unfortunately we don't have access to infrastructure setup
for such tests :(

You don't have two computers connected on a network?

All you need is that, load a bunch of routes into one system that
point to an IP address which you just force an ARP entry for (so it
just gets lost in the ether) and then generate a rDOS workload through
it from another machine using pktgen.

I'm fine with funny per-cpu memory allocation strategies, perhaps
(would have to see a patch doing _only_ that to be sure).

But using bigrefs, no way.  We have enough trouble making the data
structures small without adding bloat like that.  A busy server can
have hundreds of thousands of dst cache entries active on it, and they
chew up enough memory as is.