svn commit: r296310 - projects/vnet/sys/netinet
Marko Zec
zec at fer.hr
Wed Mar 2 15:53:09 UTC 2016
On Wed, 2 Mar 2016 11:18:18 +0000
"Bjoern A. Zeeb" <bz at freebsd.org> wrote:
> Author: bz
> Date: Wed Mar 2 11:18:17 2016
> New Revision: 296310
> URL: https://svnweb.freebsd.org/changeset/base/296310
>
> Log:
> It looks like as with the safety belt of DELAY(hz) fastened (*) we
> can completely tear down and free all memory for TCP (after r281599).
>
> (*) in theory a few ticks should be good enough to make sure the
> timers are all really gone. I wonder if we could use a better matric
> here and check a tcbcb count as an optimization.
...
> @@ -737,10 +737,18 @@ tcp_destroy(void *unused __unused)
> {
> int error;
>
> + /*
> + * All our processes are gone, all our sockets should be
> cleaned
> + * up, which means, which should past the tcp_discardcb()
> calls.
> + * Sleep to let all tcpcb timers really disappear and then
> cleanup.
> + * Timewait will cleanup it's queue and will be ready to go.
> + */
> + DELAY(hz);
With kern.hz=1000 (default value) this will sleep for a single tick
duration. With kern.hz=100 this will sleep less than a tick. Is this
the intended behavior?
> tcp_hc_destroy();
> syncache_destroy();
> tcp_tw_destroy();
> in_pcbinfo_destroy(&V_tcbinfo);
> + /* tcp_discardcb() clears the sack_holes up. */
> uma_zdestroy(V_sack_hole_zone);
> uma_zdestroy(V_tcpcb_zone);
>
>
> Modified: projects/vnet/sys/netinet/tcp_timewait.c
> ==============================================================================
> --- projects/vnet/sys/netinet/tcp_timewait.c Wed Mar 2
> 10:23:50 2016 (r296309) +++
> projects/vnet/sys/netinet/tcp_timewait.c Wed Mar 2 11:18:17
> 2016 (r296310) @@ -186,7 +186,7 @@ tcp_tw_init(void) {
>
> V_tcptw_zone = uma_zcreate("tcptw", sizeof(struct tcptw),
> - NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
> + NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
> TUNABLE_INT_FETCH("net.inet.tcp.maxtcptw", &maxtcptw);
> if (maxtcptw == 0)
> uma_zone_set_max(V_tcptw_zone, tcptw_auto_size());
>
More information about the svn-src-projects
mailing list