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

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

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