Date: Mon, 14 Jan 2013 19:47:39 +0000 (UTC) From: Alfred Perlstein <alfred@FreeBSD.org> To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r245430 - projects/utrace2/sys/kern Message-ID: <201301141947.r0EJldKD005646@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: alfred Date: Mon Jan 14 19:47:38 2013 New Revision: 245430 URL: http://svnweb.freebsd.org/changeset/base/245430 Log: Do not autotune ncallout to be greater than 18508. When maxusers was unrestricted and maxfiles was allowed to autotune much higher the result was that ncallout which was based on maxfiles and maxproc grew much higher than was needed. To fix this clip autotuning to the same number we would get with the old maxusers algorithm which would stop scaling at 384 maxusers. Growing ncalout higher is not likely to be needed since most consumers of timeout(9) are gone and any higher value for ncallout causes the callwheel hashes to be much larger than will even be needed for most applications. MFC after: 1 month Modified: projects/utrace2/sys/kern/subr_param.c Modified: projects/utrace2/sys/kern/subr_param.c ============================================================================== --- projects/utrace2/sys/kern/subr_param.c Mon Jan 14 19:31:44 2013 (r245429) +++ projects/utrace2/sys/kern/subr_param.c Mon Jan 14 19:47:38 2013 (r245430) @@ -324,8 +324,11 @@ init_param2(long physpages) /* * XXX: Does the callout wheel have to be so big? + * + * Clip callout to result of previous function of maxusers maximum + * 384. This is still huge, but acceptable. */ - ncallout = 16 + maxproc + maxfiles; + ncallout = imin(16 + maxproc + maxfiles, 18508); TUNABLE_INT_FETCH("kern.ncallout", &ncallout); /*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301141947.r0EJldKD005646>