|
On Mon, Feb 17, 2003 at 09:56:24AM +0100, Roberto Nibali wrote:
> >Unless someone has recently indulged in some /proc handywork
> >then the only way to change this is to recomile the kernel.
>
> Whoa, Horms, making this work via proc-fs would be a pretty nasty business
> :)
I definitely wouldn't condone such a thing.
I know how nasty that would be.
> >Note that if you are running LVS as a module - which is usually
> >advisable - then you only need to recompile the module.
>
> Agreed. Plus I would love to know why people always want to increase it? I
> remember that at one point we had a piece of code testing the hash table. I
> think Julian and/or Wensong wrote it. Does anyone of you still have that
> code?
Agreed. To expand on this for the benefit of others. The hash table is
just that. A hash. Each bucket in the hash can have multiple entries.
The implementation is such that each bucket is a linked list of entries.
Thus there is no limit on the number of entries the hash table can hold
(other than the amount of memory available). The only advantage of
increasing the hash table size is to reduce, statistically speaking, the
number of entries in each bucket. And thus the amount of hash table
traversal. To be honest I think the gain is probably minimal even in
extreme circumstances.
Anecdotally, a colleague of mine did a test on making the linked lists
reordering. So that the most recently used entry was moved to the front.
He then pushed a little bit traffic through the LVS box (>700Mbit/s).
We didn't really see any improvement. Which would make me think that
hash table performance isn't a particular bottleneck in the current
code.
--
Horms
|
