Re: install/56582: port-atari freeze on installation when extracting base.tgz

[David Brownlee <abs%absd.org@localhost>]

The following reply was made to PR port-atari/56582; it has been noted by GNATS.

From: David Brownlee <abs%absd.org@localhost>
To: Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-atari-maintainer%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, dross%pobox.com@localhost
Subject: Re: install/56582: port-atari freeze on installation when extracting base.tgz
Date: Fri, 7 Jan 2022 15:42:58 +0000

 On Thu, 30 Dec 2021 at 23:35, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
 >
 > On Thu, Dec 30, 2021 at 11:10:02PM +0000, David Brownlee wrote:
 > > The following reply was made to PR port-atari/56582; it has been noted by GNATS.
 > >
 > > From: David Brownlee <abs%absd.org@localhost>
 > > To: Jason Thorpe <thorpej%me.com@localhost>
 > > Cc: gnats-bugs%netbsd.org@localhost, port-atari-maintainer%netbsd.org@localhost,
 > >       gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, dross%pobox.com@localhost
 > > Subject: Re: install/56582: port-atari freeze on installation when extracting base.tgz
 > > Date: Thu, 30 Dec 2021 23:05:31 +0000
 > >
 > >  On Thu, 30 Dec 2021 at 14:49, Jason Thorpe <thorpej%me.com@localhost> wrote:
 > >  >
 > >  > > On Dec 30, 2021, at 12:10 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
 > >  >
 > >  > > mlockall() returns ENOMEM when the system- or per-process-limit is exceeded,
 > >  > > you can ignore it. Worst thing is that ntpd gets swapped out and cannot
 > >  > > sync time anymore.
 > >  > >
 > >  > > ntpd uses about 7MB RAM (about 3MB shared). You probably don't want
 > >  > > to have this locked in memory on a small machine. Adding
 > >  > >
 > >  > > rlimit memlock -1
 > >  > >
 > >  > > to ntp.conf should prevent it from trying.
 > >  >
 > >  > I wonder if we should add a heuristic in ntpd to auto-tune for this.
 > >
 > >  I'd be loudly in favour of this - people should be able to set things
 > >  explicitly, but we really should be defaulting more things based on
 > >  current memory and or relative compute level.
 >
 > Speaking as the devil's adocate: why should I care about machines with
 > 16MB as ntp author in 2021? Getting swapped out is a very real risk even
 > on larger machines and ntpd by nature is timing sensitive. So what
 > justifies the added complexity of such an option or tuning heuristic?
 
 ... and that would be a perfectly legitimate position to take. If the
 heuristic is easy and accepted o[stream then I think it's worthwhile,
 if it's too complicated, or just rejected upstream then probably not.
 
 I'd be inclined to have something along the lines of a sysctl value
 which would indicate whether "low memory behaviour" should be
 triggered, which could be picked up by a default ntp conf, or if rc.d
 should run makemandb.
 
 Interestingly nfp.conf indicates that form rlimit memlock "The default
 is 32 megabytes on non-Linux machines, and -1 under Linux", so I
 wonder if we should just look to default to -1 on shipping and allow
 people to tweak away from that
 
 David