From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 17:16:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D316FD56; Mon, 14 Jan 2013 17:16:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A958B7A2; Mon, 14 Jan 2013 17:16:29 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 9B1C51A3CE3; Mon, 14 Jan 2013 09:16:28 -0800 (PST) Message-ID: <50F43D6A.9010303@mu.org> Date: Mon, 14 Jan 2013 12:16:26 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexander Motin Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> <50F430E3.70501@FreeBSD.org> In-Reply-To: <50F430E3.70501@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------050704080205010807000909" Cc: Adrian Chadd , Andre Oppermann , Alan Cox , "Jayachandran C." , Oleksandr Tymoshenko , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:16:29 -0000 This is a multi-part message in MIME format. --------------050704080205010807000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [[ moved to -arch ]] On 1/14/13 11:22 AM, Alexander Motin wrote: > On 14.01.2013 18:05, Andre Oppermann wrote: >> On 14.01.2013 16:51, Alexander Motin wrote: >>> As I've actually written, there are two different things: >>> ncallout -- number of preallocated callout structures for purposes of >>> timeout() calls. That is a legacy API that is probably not very much >>> used now, so that value don't need to be too big. But that allocation is >>> static and if it will ever be exhausted system will panic. That is why >>> it was set quite high. The right way now would be to analyze where that >>> API is still used and estimate the really required number. >> Can timeout() be emulated on top of another API so we can do away with it? > It is already emulated on top of callout_init()/callout_reset(). The > problem is that callout_init()/callout_reset() assume storage memory to > be allocated by consumer, while timeout() assumes it to be allocated by > subsystem. The only way to solve it is to rewrite remaining timeout() > consumers to use callout_init()/callout_reset() API directly. The following diff should suffice as a fine stop-gap and is no worse than what we've lived with for the past 10 years. What it does is cap the amount of callouts to a function of maxusers as if the old limit of 384 was in place. A more comprehensive fix is not needed because we are about to do away with the entire mess anyhow. I'm doing some testing with it. Let me know what you think. -Alfred --------------050704080205010807000909 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="ncallout_max.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ncallout_max.diff" Index: subr_param.c =================================================================== --- subr_param.c (revision 245315) +++ subr_param.c (working copy) @@ -324,8 +324,11 @@ /* * 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 = min(16 + maxproc + maxfiles, 18508); TUNABLE_INT_FETCH("kern.ncallout", &ncallout); /* --------------050704080205010807000909--