From owner-freebsd-current@freebsd.org Mon Sep 9 18:45:00 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 B7D5CDBCA2 for ; Mon, 9 Sep 2019 18:45:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 46Rxt43bTMz4PGt; Mon, 9 Sep 2019 18:45:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x89Iikci082709 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 9 Sep 2019 21:44:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x89Iikci082709 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x89IikiX082708; Mon, 9 Sep 2019 21:44:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Sep 2019 21:44:46 +0300 From: Konstantin Belousov To: Ian Lepore Cc: "Rodney W. Grimes" , Cy Schubert , Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org Subject: Re: ntpd segfaults on start Message-ID: <20190909184446.GU2559@kib.kiev.ua> References: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46Rxt43bTMz4PGt X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] 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 18:45:00 -0000 On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > 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. > > > > Does it have that effect? I don't know. But I would argue that that's > a separate issue, and we should make that happen by adding > ntpd_oomprotect=YES to /etc/defaults/rc.conf Wiring process memory has no effect on OOM selection. More, because all potentially allocated pages are allocated for real after mlockall(), the size of the vmspace, as accounted by OOM, is the largest possible size from the whole lifetime. On the other hand, the code execution times are not predictable if the process's pages can be paged out. Under severe load next instruction might take several seconds or even minutes to start. It is quite unlike the scheduler delays. That introduces a jitter in the local time measurements and their usage as done in userspace. Wouldn't this affect the accuracy ? > > Right now only syslogd has oomprotect set to YES by default. Maybe > that's a good choice -- once we start declaring one daemon to be more > important than others, you'll discover there's a whole back lot full of > bikesheds that need painting. > > So maybe we should just document ntpd_oomprotect=YES in some more- > prominent way. If we were to add a comment block to ntp.conf > describing rlimit, that might be a good place to mention setting > ntpd_oomprotect in rc.conf. > > -- Ian >