tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tcp_vtw fail (was: Re: CVS commit: src)



On Tue, May 17, 2011 at 05:16:08PM -0400, Matthew Mondor wrote:
> On Tue, 17 May 2011 08:09:55 +0000
> David Holland <dholland-current%netbsd.org@localhost> wrote:
> 
> > Yeah, so this turns out to be because the tcp_vtw code unconditionally
> > allocates about 9M of memory for vestigial connection entries (or
> > some such thing) even when it's AFAICT not in use.
> 
> >  int        tcp4_vtw_enable = 0;            /* 1 to enable */
> >  int        tcp6_vtw_enable = 0;            /* 1 to enable */
> >  int        tcp_vtw_was_enabled = 0;
> > -int        tcp_vtw_entries = 1 << 16;      /* 64K vestigial TIME_WAIT 
> > entries */
> > +int        tcp_vtw_entries = 1 << 4;       /* 16 vestigial TIME_WAIT 
> > entries */
> 
> Strikes me as odd if they're really being allocated despite the feature
> being disabled.
> 
> I'm not very familiar with this other than the previous discussions
> about it here, but was 64K entries the default because it's
> performance-critical?
> 
> If so, would it be possible to dynamically resize these, controled by a
> sysctl stub (or even better, automatically via heuristics in the long
> run)?

In the short run, it is best if memory allocation is postponed until
after VTW is enabled.  I will look into it.  It may have to wait until
Monday.

In the long run, it is best if the number of entries is adjustable at
run-time.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24


Home | Main Index | Thread Index | Old Index