Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

0 views
Skip to first unread message

Matthew Mondor

unread,
May 17, 2011, 5:16:08 PM5/17/11
to
On Tue, 17 May 2011 08:09:55 +0000
David Holland <dholland...@netbsd.org> 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)?

Thanks,
--
Matt

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

der Mouse

unread,
May 17, 2011, 5:24:35 PM5/17/11
to
> 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)?

Why bother? Any modern machine can handle 64K of them just fine.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

David Young

unread,
May 17, 2011, 5:30:42 PM5/17/11
to
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...@netbsd.org> 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
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24

Izumi Tsutsui

unread,
May 26, 2011, 9:56:34 AM5/26/11
to
> > > -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.

Any progress on this issue?

sun3 and hp300 kernels have troubles with this problem
and I can't test MD changes requested by a developer...

---
Izumi Tsutsui

David Young

unread,
May 26, 2011, 6:57:59 PM5/26/11
to
On Thu, May 26, 2011 at 10:56:34PM +0900, Izumi Tsutsui wrote:
> > > > -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.
>
> Any progress on this issue?
>
> sun3 and hp300 kernels have troubles with this problem
> and I can't test MD changes requested by a developer...

Sorry I didn't send an update, earlier, it's been a busy week. I
understand the problem, and I have an idea how I will fix it. I will
try to work on it tomorrow.

Dave

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

--

0 new messages