auto tuning tcp
Peter Wemm
peter at wemm.org
Tue Nov 13 06:23:50 UTC 2012
On Mon, Nov 12, 2012 at 10:11 PM, Alfred Perlstein <bright at mu.org> wrote:
> On 11/12/12 10:04 PM, Alfred Perlstein wrote:
>>
>> On 11/12/12 10:48 AM, Alfred Perlstein wrote:
>>>
>>> On 11/12/12 10:01 AM, Andre Oppermann wrote:
>>>>
>>>>
>>>> I've already added the tunable "kern.maxmbufmem" which is in pages.
>>>> That's probably not very convenient to work with. I can change it
>>>> to a percentage of phymem/kva. Would that make you happy?
>>>>
>>>
>>> It really makes sense to have the hash table be some relation to sockets
>>> rather than buffers.
>>>
>>> If you are hashing "foo-objects" you want the hash to be some relation to
>>> the max amount of "foo-objects" you'll see, not backwards derived from the
>>> number of "bar-objects" that "foo-objects" contain, right?
>>>
>>> Because we are hashing the sockets, right? not clusters.
>>>
>>> Maybe I'm wrong? I'm open to ideas.
>>
>>
>> Hey Andre, the following patch is what I was thinking
>> (uncompiled/untested), it basically rounds up the maxsockets to a power of 2
>> and replaces the default 512 tcb hashsize.
>>
>> It might make sense to make the auto-tuning default to a minimum of 512.
>>
>> There are a number of other hashes with static sizes that could make use
>> of this logic provided it's not upside-down.
>>
>> Any thoughts on this?
>>
>> Tune the tcp pcb hash based on maxsockets.
>> Be more forgiving of poorly chosen tunables by finding a closer power
>> of two rather than clamping down to 512.
>> Index: tcp_subr.c
>> ===================================================================
>
>
> Sorry, GUI mangled the patch... attaching a plain text version.
>
>
Wait, you want to replace a hash with a flat array? Why even bother
to call it a hash at that point?
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
More information about the freebsd-net
mailing list