Date: Mon, 14 Jan 2013 12:16:26 -0500 From: Alfred Perlstein <bright@mu.org> To: Alexander Motin <mav@FreeBSD.org> Cc: Adrian Chadd <adrian@freebsd.org>, Andre Oppermann <andre@freebsd.org>, Alan Cox <alc@rice.edu>, "Jayachandran C." <jchandra@freebsd.org>, Oleksandr Tymoshenko <gonzo@bluezbox.com>, freebsd-arch@freebsd.org Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <50F43D6A.9010303@mu.org> In-Reply-To: <50F430E3.70501@FreeBSD.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <ABB3E29B-91F3-4C25-8FAB-869BBD7459E1@bluezbox.com> <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> <CA%2B7sy7CkdoyScOEDEXWuwJxjCS5zTcC8_fu9isCeTFxT8opNJQ@mail.gmail.com> <50F04FE5.7010406@rice.edu> <CA%2B7sy7D=ZjTLirGW3BVGcAu0h8-dWpib%2BYziUjEqegOL9J4adw@mail.gmail.com> <CAJ-VmonLoL4E3UsNwx87p2FuHXTbJe7wFs9hBn5Zmr7TTQOSkg@mail.gmail.com> <50F1BD69.4060104@mu.org> <CAJ-VmokjZ_vpcmYeD65pWJN5tfhqn6yDXrFFcXf8dvYc55tQtg@mail.gmail.com> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> <50F430E3.70501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
[[ 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
[-- Attachment #2 --]
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);
/*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F43D6A.9010303>