From owner-freebsd-current@freebsd.org Mon Sep 9 16:30:57 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 13408D75A0 for ; Mon, 9 Sep 2019 16:30:57 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46RtvN5YC0z4BwC; Mon, 9 Sep 2019 16:30:56 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x89GUjvG044289; Mon, 9 Sep 2019 09:30:45 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x89GUjGX044288; Mon, 9 Sep 2019 09:30:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net> Subject: Re: ntpd segfaults on start In-Reply-To: <66f80012757134b6317b673f9eeb24db66c996a2.camel@freebsd.org> To: Ian Lepore Date: Mon, 9 Sep 2019 09:30:45 -0700 (PDT) CC: Cy Schubert , Konstantin Belousov , Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 46RtvN5YC0z4BwC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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:30:57 -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. Doesn't locking this memory down also protect ntpd from OOM kills? If so that is a MUST preserve functionality, as IMHO killing ntpd on a box that has it configured is a total no win situation. Regards, Rod > 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 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org