All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Bill Fink <billfink@mindspring.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
	jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Subject: Re: [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded
Date: Thu, 02 Oct 2008 10:15:38 +0200	[thread overview]
Message-ID: <48E4832A.3070804@cosmosbay.com> (raw)
In-Reply-To: <48E470AC.10305@cosmosbay.com>

Eric Dumazet a écrit :
> Bill Fink a écrit :
>> On Wed, 1 Oct 2008, Neil Horman wrote:
>>
>>> Hey all-
>>>     Since Eric mentioned the use of statistical analysis to determine if
>>> hash chains were growing improperly, I thought I would take a stab at 
>>> such an
>>> approach.  I'm no statistics expert, but it would seem to me that simply
>>> computing the standard deviation of all the non-zero chain lengths 
>>> would give a
>>> good guide point to determine if we needed to invalidate our hash 
>>> table.  I've
>>> written the below implementation.  I've not tested it (I'll be doing 
>>> that here
>>> shortly for the next few days), but I wanted to post it to get 
>>> feedback from you
>>> all on the subject.  The highlights are:
>>>
>>> 1) We add a counter to rt_hash_bucket structure to track the length 
>>> of each
>>> individual chain.  I realize this is sub-optimal, as it adds 
>>> potentially lots of
>>> memory to hash table as a whole (4 bytes * number of hash buckets).  
>>> I'm afraid
>>> I've not come up with a better way to track that yet.  We also track 
>>> the total
>>> number of route entries and the number of non-zero length chains.  
>>> Lastly we
>>> also maintain a global maximum chain length which defines the longest 
>>> chain we
>>> will tolerate in the route table.  This patch defines it as the mean 
>>> chain
>>> length plus one standard deviation.
>>
>> I believe the general rule of thumb for something like this is at
>> least two standard deviations.  For a normal distribution, one standard
>> deviation covers about 68 % of the sample universe, while two standard
>> deviations covers about 95 % (three standard deviations covers 99.73 %).
>> See the Wikipedia entry:
>>
>>     http://en.wikipedia.org/wiki/Standard_deviation
>>
> 
> Thanks Bill for the pointer, this is the trick.
> 
> I believe we should target "4σ 99.993666% " case.
> 
> But we dont need to really compute Standard deviation at runtime, only 
> find an (upper) approximation of it.
> 
> For elasticity=4 and 512*1024 samples (mean < 4), I guess 4σ can be 
> approximated by 20 or something.
> 

Good estimation of Standard Deviation could be computed for free
in rt_check_expire(). (each runs scans 20% of hash table with 
default tunables timeout & ip_rt_gc_interval)

We could update 4σ estimation in this function, every minute (ip_rt_gc_interval)

At softirq time we then can detect a particular hash chain is
longer than 4σ estimation and trigger an appropriate action.

This action is to : flush table, and while we do that, expand hash table
if its current size is under ip_rt_max_size/elasticity...





  reply	other threads:[~2008-10-02  8:19 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29 19:12 [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded Neil Horman
2008-09-29 20:22 ` Eric Dumazet
2008-09-29 20:27   ` Neil Horman
2008-09-29 21:00     ` Eric Dumazet
2008-09-29 22:38       ` Neil Horman
2008-09-30  6:02         ` Eric Dumazet
2008-09-30 11:23           ` Neil Horman
2008-09-30 14:10           ` David Miller
2008-09-30 17:16             ` Eric Dumazet
2008-09-30 18:42               ` Neil Horman
2008-10-02  7:16                 ` Evgeniy Polyakov
2008-10-02 13:14                   ` Neil Horman
2008-10-01 18:08               ` Neil Horman
2008-10-02  5:01                 ` Bill Fink
2008-10-02  6:56                   ` Eric Dumazet
2008-10-02  8:15                     ` Eric Dumazet [this message]
2008-10-02 14:20                       ` Eric Dumazet
2008-10-03  0:31                       ` Neil Horman
2008-10-03 20:36                         ` Neil Horman
2008-10-06 10:49                           ` Eric Dumazet
2008-10-06 13:14                             ` Neil Horman
2008-10-06 20:54                             ` Neil Horman
2008-10-06 21:21                               ` Eric Dumazet
2008-10-06 22:52                                 ` Neil Horman
2008-10-07  5:13                                   ` Eric Dumazet
2008-10-07 10:54                                     ` Neil Horman
2008-10-13 18:26                                     ` Neil Horman
2008-10-16  6:55                                       ` David Miller
2008-10-16  9:19                                         ` Eric Dumazet
2008-10-16 21:18                                           ` David Miller
2008-10-16 11:41                                         ` Neil Horman
2008-10-16 12:25                                           ` Eric Dumazet
2008-10-16 16:36                                             ` Neil Horman
2008-10-16 23:35                                               ` Neil Horman
2008-10-17  4:53                                                 ` Eric Dumazet
2008-10-17  5:23                                                   ` David Miller
2008-10-17  5:03                                                 ` Stephen Hemminger
2008-10-17  5:06                                                 ` Stephen Hemminger
2008-10-17 10:39                                                   ` Neil Horman
     [not found]                                                     ` <48F8806A.6090306@cosmosbay.com>
     [not found]                                                       ` <20081017152328.GB23591@hmsreliant.think-freely.org>
     [not found]                                                         ` <48F8AFBE.5080503@cosmosbay.com>
2008-10-17 20:44                                                           ` Neil Horman
2008-10-18  0:54                                                             ` Neil Horman
2008-10-18  4:36                                                               ` Eric Dumazet
2008-10-18 13:30                                                                 ` Neil Horman
2008-10-20  0:07                                                                 ` Neil Horman
2008-10-20  8:12                                                                   ` Eric Dumazet
2008-10-27 19:28                                                                     ` David Miller
2008-10-02  7:13               ` Evgeniy Polyakov
2008-09-30 14:08   ` David Miller
2008-09-30 14:08 ` David Miller
2008-09-30 17:47   ` Eric Dumazet
2008-10-05  3:26   ` Herbert Xu
2008-10-05  4:45     ` Andrew Dickinson
2008-10-05 17:34       ` David Miller
2008-10-05 18:06         ` Andrew Dickinson
2008-10-06  4:21         ` Herbert Xu
2008-10-06 10:50           ` Neil Horman
2008-10-06 11:02             ` Herbert Xu
2008-10-06 12:43               ` Neil Horman
2008-09-30 14:17 ` Denis V. Lunev
2008-09-30 14:35   ` Neil Horman
2008-09-30 14:49     ` Denis V. Lunev
2008-10-05  3:17 ` Herbert Xu
2008-10-05  3:20   ` Herbert Xu
2008-10-06  0:52     ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48E4832A.3070804@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=billfink@mindspring.com \
    --cc=davem@davemloft.net \
    --cc=jmorris@namei.org \
    --cc=johnpol@2ka.mipt.ru \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=pekkas@netcore.fi \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.