On Tue, 9 Dec 2003 16:09:07 +0100
Robert Olsson <Robert.Olsson@xxxxxxxxxxx> wrote:
> I think patch should be useful as it helps performance a lot during high
> flow load. I have some numbers if you are interested.
I'm very hesitant about this, and it is not because I don't believe
that it brings better performance in your tests on your machines :)
Recently there was a thread on linux-kernel by the folks, such as Jes,
working on super-duper-huge NUMA boxes and how big the hash tables
get sized to on these machines.
In some of their configurations it was trying to allocate 1GB TCP
hash tables or something totally rediculious like this.
The problem with all of our current algorithms for size selection is
that it considers only one parameter when there are actually two.
It considers currently only relative memory consumption. It needs
to also consider hard limits that exist for useful hash table sizes.
There is a point at which hash table size exceeds it's usefulness in
that the gains you are getting from the O(1) lookup are offset by the
fact that the access to the hash table heads are constantly taking cpu
cache misses.
You've obtained good results in your tests with a _specific_ hash
table size for the routing cache, but the algorithm you are proposing
for the kernel computes things relative to the amount of memory in the
machine. It cannot be a function of only this parameter.
Do you see my point?
|