Date: Fri, 7 Nov 2008 08:58:03 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Anton Yuzhaninov <citrin@citrin.ru> Cc: freebsd-net@freebsd.org Subject: Re: sysctl net.inet.tcp.syncache.count Message-ID: <alpine.BSF.1.10.0811070847100.99966@fledge.watson.org> In-Reply-To: <49137561.80403@citrin.ru> References: <49137561.80403@citrin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Nov 2008, Anton Yuzhaninov wrote: > % sysctl net.inet.tcp.syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 1024 > net.inet.tcp.syncache.count: -84 > net.inet.tcp.syncache.cachelimit: 102400 > net.inet.tcp.syncache.bucketlimit: 100 > > Why number of entries in syncache is negative? The syncache entry is no longer protected by a single lock, since the locks on the syncache are now per-hash bucket, so it looks like it's been corrupted. This won't lead to other problems, as the count is updated as a statistic but never used to, for example, enforce limits. We should probably eliminate the statistic, since UMA already maintains the syncache entry count coherently as part of its own statistics, along with other useful information: robert@fledge:~> vmstat -z | head -1 ; vmstat -z | grep -i syncache ITEM SIZE LIMIT USED FREE REQUESTS FAILURES syncache: 104, 15392, 0, 222, 2638489, 0 I'm not convinced its worth adding the overhead of coherent statistics gathering for the cache entry count if we already have it elsewhere. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0811070847100.99966>