> 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
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
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
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
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
--