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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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?

Joerg