From nobody Wed Nov 9 02:15:32 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 4N6T8t7011z4XMms for ; Wed, 9 Nov 2022 02:15:58 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 4N6T8t543pz454n for ; Wed, 9 Nov 2022 02:15:58 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-369426664f9so150198777b3.12 for ; Tue, 08 Nov 2022 18:15:58 -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=yiUGOaqzYFdt08gpitYncF/qk5kV/GO81dF0qhXdp7w=; b=IRGskljUWv85OYRNkpXVS3UoZLP//wjvFts/1KfXwWhPsV7sIq7YeI6d4BX3BbZyGl dNOKWd8I00mZzJZbe1pSxT01+Sdy5WpdT//AzdIJ5sUWO1F+a0cDg3GQCTB8c2Us7m/F VYIBea6g3hYul0DvtCWVgTJ9NTzrUZtVu/VChras0bDsjzJ1ZAlrhSy+HL62zb6cdPqZ 2Ag4O0vVEKOhk29EG7BDRpolu+64Gm8fr27nUu4VrLvz+QQmbMDJ89d96LLyDWLizqNB m/8JaAcBaRCV6tDv4PPoBgJFEQj2HOJJ/aCdTt7nGds59wW8pY31FpnqtyN/NAq5/AFB L+Gw== 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=yiUGOaqzYFdt08gpitYncF/qk5kV/GO81dF0qhXdp7w=; b=1To1Jf0XmK+MUzyJowR44TB8+HokR4hjJ+dG7db0z16EzUrC2JVyNdJJsPBLGINGE+ MpturYX7WHH9Vorbsk6LBBmnfMWi04lV/UnAlLKzNi3HZh37RJ3wGAPOGeXZLcmehRqW Mk/wYsQHrJ8CftUnbgH60fna3xmF50WNvccP04E9+g9kjB3e64HV+iLWegSXl8upBF2E fQbAdAqzSOEahCwmDoa+OWur/j8gfeNWQ6Hh9/QoHxcq4kVC7Dr0KiJzA7V3HxcX34Ui i+H2Eroz3B58ual9gOgjVBe3rReJunr+twd2LLBOa681XXq63sA+yneM9qqPnHpiDMf1 aXng== X-Gm-Message-State: ACrzQf2lpwhpGRCRp4mk0GlNOESJel5rCRu2EyrSi1Hrhkq4jcCQzVGN DUI8Xc5iUx1ZGkRhm2s42d4i/eOSaJRUi85uWO8= X-Google-Smtp-Source: AMsMyM6NLa00zi8rWbV1YjvVb/qqNUdz+qKeOQrEfc73tWohYv2W/VbUmFiBFpGHfNrQyi0HimyzZxXh5lkc0ngSkpk= X-Received: by 2002:a81:4bcf:0:b0:367:bdfb:d0eb with SMTP id y198-20020a814bcf000000b00367bdfbd0ebmr56654861ywa.105.1667960157951; Tue, 08 Nov 2022 18:15:57 -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> <1722758786.127406.1667909706281@localhost> <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com> In-Reply-To: <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com> From: Archimedes Gaviola Date: Wed, 9 Nov 2022 10:15:32 +0800 Message-ID: Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build To: Mark Millard Cc: Ronald Klop , freebsd-current Content-Type: multipart/alternative; boundary="000000000000b6dc8305ed003cfa" X-Rspamd-Queue-Id: 4N6T8t543pz454n 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --000000000000b6dc8305ed003cfa Content-Type: text/plain; charset="UTF-8" On Wed, Nov 9, 2022 at 1:37 AM Mark Millard wrote: > On Nov 8, 2022, at 04:15, Ronald Klop wrote: > > > Van: Warner Losh > > Datum: dinsdag, 8 november 2022 04:28 > > Aan: Archimedes Gaviola > . . . > > ... > > 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 > > This means that paging to the swap partition and/or swap file took too > long (> 30 seconds... that's all that indefinite means). It also means that > it can't write to backing store dirty pages to give to another process... > > Typical reason is that the disk / flash is not responsive to writes > for some reason. You'll need to find why... I'd look at trims. > > Or.... if you can't change the disk... you need to put less memory > pressure on it.. > > Warner > > > > > > > > NB: a way to put less memory pressure on it is not using -j3, but -j2 or > -j1 in your make command. > > > Hi Mark, > Extending Ronold's comment: If things are really taking this > long for the paging I/O, you might actually find, say, -j2 > takes less elapsed time than -j3 because of the latencies > involved in -j3 causing more overall delay. > Yes I'll take these options on lowering down N in the -jN parameter as my next steps. So far so good with -j3, ongoing build is still observed for 17 hours now. > > vm.pfault_oom_attempts=-1 would still be appropriate for avoiding > I/O kills at any -jN: the smaller -jN just makes the issue less > likely, not impossible. (Again, presuming sufficient swap/paging > space if deadlock is to be well avoided.) > The ongoing build is at the moment on /usr/src/contrib/llvm-project/llvm/lib/*. I'm observing from time-to-time if the error will occur again. > (I use NVMe or SSD USB media that do not get such long delays but > fit the power limitations of the context. I have about as little > on microsd card media as I can get away with in my context. I also > avoid spinning rust. Thus I've only gotten "indefinite wait buffer" > or the like back before such was true, long ago.) > Okay thanks for sharing this one. Keeping this in my mind just in case I needed these types of media soon. Thanks and best regards, Archimedes --000000000000b6dc8305ed003cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 9, 2022 at 1:37 AM Mark M= illard <marklmi@yahoo.com> w= rote:
On Nov 8, = 2022, at 04:15, Ronald Klop <ronald-lists@klop.ws> wrote:

> Van: Warner Losh <imp@bsdimp.com>
> Datum: dinsdag, 8 november 2022 04:28
> Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com
> . . .
> ...
> 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
>=C2=A0 =C2=A0This means that paging to the swap partition and/or swap f= ile took too long (> 30 seconds... that's all that indefinite means)= . It also means that it can't write to backing store dirty pages to giv= e to another process...
>=C2=A0 =C2=A0Typical reason is that the disk / flash is not responsive = to writes for some reason. You'll need to find why... I'd look at t= rims.
>=C2=A0 =C2=A0Or.... if you can't change the disk... you need to put= less memory pressure on it..
>=C2=A0 =C2=A0Warner
>=C2=A0 =C2=A0
>
>
> NB: a way to put less memory pressure on it is not using -j3, but -j2 = or -j1 in your make command.
>

Hi Mark,
=C2=A0
Extending Ronold's comment: If things are really taking this
long for the paging I/O, you might actually find, say, -j2
takes less elapsed time than -j3 because of the latencies
involved in -j3 causing more overall delay.

=
Yes I'll take these options on lowering down N in the -jN paramete= r as my next steps. So far so good with -j3, ongoing build is still observe= d for 17 hours now.
=C2=A0

vm.pfault_oom_attempts=3D-1 would still be appropriate for avoiding
I/O kills at any -jN: the smaller -jN just makes the issue less
likely, not impossible. (Again, presuming sufficient swap/paging
space if deadlock is to be well avoided.)

The ongoing build is at the moment on /usr/src/contrib/llvm-project/llvm= /lib/*. I'm observing from time-to-time if the error will occur again.<= br>
=C2=A0
(I use NVMe or SSD USB media that do not get such long delays but
fit the power limitations of the context. I have about as little
on microsd card media as I can get away with in my context. I also
avoid spinning rust. Thus I've only gotten "indefinite wait buffer= "
or the like back before such was true, long ago.)

=
Okay thanks for sharing this one. Keeping this in my mind just i= n case I needed these types of media soon.

Thanks = and best regards,
Archimedes

--000000000000b6dc8305ed003cfa--