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

[Matthew Mondor]

On Tue, 17 May 2011 08:09:55 +0000

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,

[der Mouse]

Post by Matthew Mondor
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 ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[David Young]

Post by Matthew Mondor
On Tue, 17 May 2011 08:09:55 +0000

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

[Izumi Tsutsui]

Post by David Young

Post by Matthew Mondor

-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

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

[David Young]

Post by Izumi Tsutsui

Post by David Young

Post by Matthew Mondor

-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