From owner-freebsd-current@freebsd.org Mon Sep 9 16:23:47 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 89560D7296 for ; Mon, 9 Sep 2019 16:23:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Rtl716H5z4BWv for ; Mon, 9 Sep 2019 16:23:46 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1568046225; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=DMHRkqd0qMhzvhET7okL/oQvH8SjkRcvPx88TQRMVHB7aX64XlkD6FCrra7/rMpBBc799XwLUqQxT /OI7Rbcasg95iwquePimpd+KnC8jGfC5S4rB4PdWBoGh5PMHD8DRpg4Mhsn0FM0FC4M9lq/3HJ5yfa CHCsj08P10zev4Gwf9JhjaFTAkYywSowcmRtqg2qWoBXi37ytmTOj2zIqiEOzMin1Gpbvk0zSd7hAQ DKWPscSiTJdKYMZZiJIVcfFMoZWnBH+rZP2Z83Xfyw7158pgwsmo5h7Opd7oL+dRXKEWK0crxf9hu6 2f0lFT16zDLjZRAZFJfYk8kzzlB4ooA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=ud7Q7xdQPRE4fkkD0wRKHXhnzBfclKNdJdmcyv1JiSk=; b=jNH1WQhvhkicmjFXaklmSha6Ha/KgCcAkmBy9FKNGZHcpDJDoVWPz1Cq+X0OT9g1QrSW/X7BN4dSN QdQuflvOOJrO6JnFCepPlcNsHyRcvBWOf/GlbAzkILTM0JBvvSgjROl4Ui9MMPddSGSRxzEFb3pabY rkMxvAUBQC0Gz99nZeIbeWDYPmrqY2j1oXe3SJwx0oVx64qer/3S2yvnjdK8zsyvw92lMtUuKr6X7P wotu78zdjBPAVrv0/GQmJuNzWl3Oo98NeTP/56UPKHPmZio3jizFpobKo+y7HgNerF3SJet9Z/XLYM kdlxyw34CUJmLO1fDA0ijHOhFCU0RrQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=ud7Q7xdQPRE4fkkD0wRKHXhnzBfclKNdJdmcyv1JiSk=; b=rkpLS3dwfbw0nskVY1CZJPx/JMpX9qtSDolcCFAU30LzVzMQy/LgJt7Bvs6WwsCBFzJpqqinz9z6X JjLec9EDDYORsxcooJHJ3SJyyizWILoj4+0DytMkzaCWdf8EDDysi++Z2GINmanQaKWsfDS/wBtRiH MQ7c2xTgjzw3tBL+oCaP1javiQvck8ON+Kl5Uj73KxLXdct3XdOSxKG3tLMJ+VC+hah7EoZg69zdVE cLprhVbXEem2gjq6FpdkOmbCnst984NzOjCjbq4+hAl+XH3JrqlqGNHKVmgs8DxcCdftWgkCiLpDqa 8MkC6gJdNDeL80SNCT7PrIMecIIDz4A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 2f71b0be-d31e-11e9-b67d-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 2f71b0be-d31e-11e9-b67d-cdd75d6ce7a8; Mon, 09 Sep 2019 16:23:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x89GNeFc062698; Mon, 9 Sep 2019 10:23:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <66f80012757134b6317b673f9eeb24db66c996a2.camel@freebsd.org> Subject: Re: ntpd segfaults on start From: Ian Lepore To: Cy Schubert , Konstantin Belousov Cc: Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org Date: Mon, 09 Sep 2019 10:23:40 -0600 In-Reply-To: <201909071628.x87GSFPV005827@slippy.cwsent.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46Rtl716H5z4BWv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] 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 16:23:47 -0000 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 wants. > > > 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. I would propose that for freebsd, the autoconf-generated value for 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 . -- Ian