From nobody Tue Nov 8 06:50:19 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5zJR1Rh7z4hYjY for ; Tue, 8 Nov 2022 06:50:47 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5zJQ6WPwz3J24 for ; Tue, 8 Nov 2022 06:50:46 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id j2so16320796ybb.6 for ; Mon, 07 Nov 2022 22:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PPkcumAW3cR0UEoHxXLW/BGUmtVi0ojslBkFQ9nGBJs=; b=hx4UC5SO4zbRAw/y+dIwasYC0EnyAJSxHljFW0A1T0/zT8U4uICWRr7AEZJVLROsyy rFsjc+VR2iJDRwUlvBBlsqh7nwBax0eofdk6HXITsdfgRw5VxSqED29nrChQPPHsLN29 IUdIN7PR6oise+BCvm7kVUG2Mg1K+QHc2iOlHe1JwDkK0NsqjNkSPDCWPYBCEwhhlOol vDpLgeVDtdJ0Q3nHQ/vLquDo8I/G0122BudqMsmz8VEz7uko54qUJu2h6DQveMB5Q/5U tzcVuhUdX6sJLiZsJ+Shjiwdt+QXouYSGuWmAtq5Gnz5MlpoWViq727Qp7rkfDGOAwbN RLLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PPkcumAW3cR0UEoHxXLW/BGUmtVi0ojslBkFQ9nGBJs=; b=zK3kkwXlEhrVhnKXNvzTyRmZVDYatdp0EQEa50HTgojnLn5m75w1iu06ZvyJGA6KQz MASm2VfAAlqQVO0akOQeBM1Zz7hbok66J9P467SC4pNgzE1Eo0ed+EGJWIGGQ/1T2a5Y DqAODYJYYqh90+zbcW6qayJdxb/9AqdGbygrEClcnEHaCDX3L9/GvA6lvPpysxnqSEer WuAMUYKZsr1+5TpTP39/KkDeIPVTbU2BJkpOpnikEo/k7pQNR0pcLklifBE4mNoH1A/d pdQSn9BW0SBe3uX4fusu3qrqH6pg5v02az03YTG0BiztphtY1cwGlG6goVhNpZv/5MhF QuQA== X-Gm-Message-State: ACrzQf2Vuc/qApIRtwHMgQsG2GagF3uvAqBPF407CPHbN1fSisNe36NO SgBwo3W44OeDPHD/iliQcizwe1rIqT32FkR/mku/a2znPWE= X-Google-Smtp-Source: AMsMyM5kWpiXpe3BEh5hOobELpk10zQVIS+eXKc3rWYvZHaJARAFU42gXomhj/3m/u47T9Y08BQnVsL2uPvN9TKAbMY= X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id m128-20020a253f86000000b006bc0998873emr54247420yba.152.1667890245763; Mon, 07 Nov 2022 22:50:45 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com> <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> In-Reply-To: From: Archimedes Gaviola Date: Tue, 8 Nov 2022 14:50:19 +0800 Message-ID: Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build To: Mark Millard Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000009f850205eceff5e7" X-Rspamd-Queue-Id: 4N5zJQ6WPwz3J24 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000009f850205eceff5e7 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 8, 2022 at 11:25 AM Mark Millard wrote: > On Nov 7, 2022, at 18:40, Archimedes Gaviola > wrote: > > > . . . > > > > Hi Mark, > > > > With this set of build commands now, > > > > # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld > kernel-toolchain buildkernel installworld installkernel distribution > DESTDIR=/home/freebsd/rpi3b > > > > in RPi 3B, I encountered the other OOM error which is the 'thread waited > too long to allocate a page'. This occurred from every build I conducted. > Though the first error on 'failed to reclaim memory' was never experienced > again. Below are the error logs. > > ... > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960 > > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to > allocate a page > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192 > > > > Perhaps some further tweaks are needed in the system so I set aside my > RPi 3B temporarily and switched over to my RPi 4B using the same microSD > card and USB flash drive (3.5 GB swap partition device) and the build > completed successfully. It took around 30 hours to complete. This RPi 4B > has 2GB RAM capacity while the RPi 3B has 1GB. From here, I'll continue > looking further for system tunables in RPi 3B which has lesser RAM capacity. > Hi Mark, > Given that you have added enough swap/paging > space to avoid needing more: > > # > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > vm.pfault_oom_attempts=-1 > > With the above setting, if you did run out of > swap/paging space and needed more, deadlocks > would be possible as I understand. The above > disables getting that type of OOM kill > completely but, effectively, a deadlock is > sort of a form of less-controlled kill. > Okay, confirmed the existing value is 3. root@generic:~ # sysctl vm.pfault_oom_attempts vm.pfault_oom_attempts: 3 and is writable as tested. root@generic:~ # sysctl vm.pfault_oom_attempts=-1 vm.pfault_oom_attempts: 3 -> -1 > There is an alternative, but I've no clue how to > find what values to set for any specific context. > I just know the names and default values (as of > when I last checked such defaults): > > # > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes (showing defaults at the time): > #vm.pfault_oom_attempts= 3 > #vm.pfault_oom_wait= 10 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied, even for nearly the same total.) > > (Yes, one of those names is the same as was set > to -1 in the earlier suggestion above. -1 > disables making attempts and just waits as long > as it takes. That makes vm.pfault_oom_wait > irrelevant in that kind of context.) > > As for where the settings can be placed . . . > > # sysctl -T vm.pfault_oom_attempts > vm.pfault_oom_attempts: -1 > > # sysctl -T vm.pfault_oom_wait > vm.pfault_oom_wait: 10 > > (So /boot/loader.conf is appropriate: loader tunables.) > Okay noted this. > > # sysctl -W vm.pfault_oom_attempts > vm.pfault_oom_attempts: -1 > > # sysctl -W vm.pfault_oom_wait > vm.pfault_oom_wait: 10 > Checking these values... root@generic:~ # sysctl -T vm.pfault_oom_attempts vm.pfault_oom_attempts: -1 root@generic:~ # sysctl -T vm.pfault_oom_wait vm.pfault_oom_wait: 10 > (So /etc/sysctl.conf or the like is an alternative: > Also writable.) > Okay this is noted. Thanks and best regards, Archimedes --0000000000009f850205eceff5e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Nov 8, 2022 at 11:25 AM Mark Millard <marklmi@yahoo.com> wrote:
On Nov 7, 2022, at 18:= 40, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> . . .
>
> Hi Mark,
>
> With this set of build commands now,
>
> # cd /usr/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildworl= d kernel-toolchain buildkernel installworld installkernel distribution DEST= DIR=3D/home/freebsd/rpi3b
>
> in RPi 3B, I encountered the other OOM error which is the 'thread = waited too long to allocate a page'. This occurred from every build I c= onducted. Though the first error on 'failed to reclaim memory' was = never experienced again. Below are the error logs.
> ...
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 40= 96
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096=
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40= 960
> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to= allocate a page
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28= 672
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192=
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 40= 96
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 81= 92
>
> Perhaps some further tweaks are needed in the system so I set aside my= RPi 3B temporarily and switched over to my RPi 4B using the same microSD c= ard and USB flash drive (3.5 GB swap partition device) and the build comple= ted successfully. It took around 30 hours to complete. This RPi 4B has 2GB = RAM capacity while the RPi 3B has 1GB. From here, I'll continue looking= further for system tunables in RPi 3B which has lesser RAM capacity.

Hi Mark,


Given that you have added enough swap/paging
space to avoid needing more:

#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
vm.pfault_oom_attempts=3D-1

With the above setting, if you did run out of
swap/paging space and needed more, deadlocks
would be possible as I understand. The above
disables getting that type of OOM kill
completely but, effectively, a deadlock is
sort of a form of less-controlled kill.

Okay, confirmed the existing value is 3.

root= @generic:~ # sysctl vm.pfault_oom_attempts
vm.pfault_oom_attempts: 3

and is writable as tested.

r= oot@generic:~ # sysctl vm.pfault_oom_attempts=3D-1
vm.pfault_oom_attempt= s: 3 -> -1
=C2=A0
There is an alternative, but I've no clue how to
find what values to set for any specific context.
I just know the names and default values (as of
when I last checked such defaults):

#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes (showing defaults at the time):
#vm.pfault_oom_attempts=3D 3
#vm.pfault_oom_wait=3D 10
# (The multiplication is the total but there
# are other potential tradoffs in the factors
# multiplied, even for nearly the same total.)

(Yes, one of those names is the same as was set
to -1 in the earlier suggestion above. -1
disables making attempts and just waits as long
as it takes. That makes vm.pfault_oom_wait
irrelevant in that kind of context.)

As for where the settings can be placed . . .

# sysctl -T vm.pfault_oom_attempts
vm.pfault_oom_attempts: -1

# sysctl -T vm.pfault_oom_wait
vm.pfault_oom_wait: 10

(So /boot/loader.conf is appropriate: loader tunables.)

Okay noted this.
=C2=A0

# sysctl -W vm.pfault_oom_attempts
vm.pfault_oom_attempts: -1

# sysctl -W vm.pfault_oom_wait
vm.pfault_oom_wait: 10

Checking these v= alues...

root@generic:~ # sysctl -T vm.pfault_oom_= attempts
vm.pfault_oom_attempts: -1

root@generic:~ # sysctl -T vm= .pfault_oom_wait
vm.pfault_oom_wait: 10

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
(So /etc/sysctl.conf or the like is an alternative:
Also writable.)

Okay this is noted.

Tha= nks and best regards,
Archimedes
<= /div>
--0000000000009f850205eceff5e7--