From owner-freebsd-current@freebsd.org Mon Sep 9 19:21:48 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9258ADCB6B for ; Mon, 9 Sep 2019 19:21:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46RyhW3C97z4RbJ; Mon, 9 Sep 2019 19:21:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 7PEKitZ6asAGk7PEMiQHYZ; Mon, 09 Sep 2019 13:21:44 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=DdwSh0sFBUtyfsAMNqAA:9 a=0_iv0QpZzRoiHx9C:21 a=HJwVhIzJ0gusrvkh:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 97C18A99; Mon, 9 Sep 2019 12:21:39 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x89JLdLp051527; Mon, 9 Sep 2019 12:21:39 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x89JLcBv051522; Mon, 9 Sep 2019 12:21:38 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201909091921.x89JLcBv051522@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: Cy Schubert , Konstantin Belousov , Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org Subject: Re: ntpd segfaults on start In-reply-to: <66f80012757134b6317b673f9eeb24db66c996a2.camel@freebsd.org> References: <201909051307.x85D7MGs034053@slippy.cwsent.com> <20190905142817.GB2559@kib.kiev.ua> <201909060355.x863tRhP089169@slippy.cwsent.com> <201909060639.x866dJ7f090176@slippy.cwsent.com> <201909062356.x86NuKdk003780@slippy.cwsent.com> <156d1e7c-0dbb-8707-90b3-13ae97c87449@nwtime.org> <20190907075619.GG2559@kib.kiev.ua> <201909071309.x87D9GxZ089964@slippy.cwsent.com> <20190907153226.GI2559@kib.kiev.ua> <201909071545.x87FjLS6004448@slippy.cwsent.com> <20190907161749.GJ2559@kib.kiev.ua> <201909071628.x87GSFPV005827@slippy.cwsent.com> <66f80012757134b6317b673f9eeb24db66c996a2.camel@freebsd.org> Comments: In-reply-to Ian Lepore message dated "Mon, 09 Sep 2019 10:23:40 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Sep 2019 12:21:38 -0700 X-CMAE-Envelope: MS4wfJtQIxh5ZXCHWA13c9h8NEFmOVKf05hF8UW4wVpcTjWQ+osI1B3orEhQr1RZqzteT6LpKEaU6LE/N72UrXmemDrdL1FVw7225J4NN0bMTgPpjpIo6p7z QD4IqtxawWrfG6z8ts+52npNW8x+49bVZg8V4E6wSZxzlEthzofuU1kDEwSkb3epeWptH8FNa8GWmy2XWOGInajVgDrf/idHj3skObBh1FziaMPkSdtr2MRD x+3zU4hiX8uuWMzK2uLk7g== X-Rspamd-Queue-Id: 46RyhW3C97z4RbJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.04 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[13.134.59.64.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.44)[ip: (-6.65), ipnet: 64.59.128.0/20(-3.08), asn: 6327(-2.39), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 19:21:48 -0000 In message <66f80012757134b6317b673f9eeb24db66c996a2.camel@freebsd.org>, Ian Le pore writes: > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > In message <20190907161749.GJ2559@kib.kiev.ua>, Konstantin Belousov writes: > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is > > > > letting it default to 0 which allows ntp to mlockall() anything it want > s. > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > Default stack size on amd64 is 512M, and default stack gap percentage is > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough > > > for the stack of the main thread of ntpd, then fine. > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > [...] > > I haven't seen anyone ask what I consider to be the crucial question > yet: why are we locking ntpd into memory by default at all? > > I have seen two rationales for ntpd using mlockall() and setrlimit(): > > - There are claims that it improves timing performance. > > - Because ntpd is a daemon that can run for months at a time, > setting limits on memory and stack growth can help detect and > mitigate against memory leak problems in the daemon. > > I am *highly* skeptical of claims that locking ntpd in memory will > improve timing performance on freebsd (to the point where I'm inclined > to dismiss them out of hand, but I'd be willing to look at any actual > evidence). > > The second point has at least some validity, but would be better > implemented (IMO) by decoupling the address space limit from the act of > locking down memory, and allowing configuration of RLIMIT_AS separately > from RLIMIT_MEMLOCK. If there's any interest in this, I could try to > put together a patchset and submit it upstream for that. Our upstream is already cc'd on this thread. diff --git a/usr.sbin/ntp/config.h b/usr.sbin/ntp/config.h index 56dbfedba6e..b26dd417885 100644 --- a/usr.sbin/ntp/config.h +++ b/usr.sbin/ntp/config.h @@ -287,7 +287,7 @@ #define DEFAULT_HZ 100 /* Default number of megabytes for RLIMIT_MEMLOCK */ -#define DFLT_RLIMIT_MEMLOCK 32 +#define DFLT_RLIMIT_MEMLOCK -1 /* Default number of 4k pages for RLIMIT_STACK */ #define DFLT_RLIMIT_STACK 50 But I'd wait for Harlan to weigh in on this. I agree with kib@ that this may introduce unwanted jitter. I'd also want to understand why this defaults to -1 for Linux only. > > I would propose that for freebsd, the autoconf-generated value for For the port but in base we control this directly. > DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and > mlockall() by default. Then in the ntp.conf we distribute we have a > section like: > > # To lock ntpd into memory, uncomment the following rlimit line. > # This should not be necessary on most systems, but may improve > # performance on heavily-loaded servers experiencing enough > # memory pressure to cause ntpd to be paged out. > # rlimit memlock stacksize > > Then we would need to come up with reasonable values for . I haven't had a chance to look at this in depth yet but I suspect that isn't in fact 32 as specified in config.h. It behaves as if this is set to 0 to mlockall() all it asks for. > > -- Ian -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.