Date: Sun, 20 Nov 2022 20:24:15 -0800 From: Mark Millard <marklmi@yahoo.com> To: Archimedes Gaviola <archimedes.gaviola@gmail.com> Cc: Ronald Klop <ronald-lists@klop.ws>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build Message-ID: <320C43A9-74FF-4848-9035-98BA1B71C44E@yahoo.com> In-Reply-To: <CAJFbk7G05iJgCADDJPPr-3qu8J9GcvS35aUOkWt5DC_UNcDYFA@mail.gmail.com> References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com> <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> <CAJFbk7FfYPSe3eF00HgDdebW70HKp5zKR0JaChTVniUDPG2qxQ@mail.gmail.com> <CA350C16-3604-4D88-9C14-040A45F6F125@yahoo.com> <CAJFbk7Hxvr9gs7GnniWtJ-QEH4yjYbB9S-vKVLjipa8v5VHa%2Bw@mail.gmail.com> <CAJFbk7GQhvgQS-23jFfFf=ershgGNKByHR8ug08Df8merwkh6Q@mail.gmail.com> <A11AA52B-BDB0-43C7-BF85-3C252B276F17@yahoo.com> <CAJFbk7HnFTdzANtdERqvgX30hcHmufAZmrNvbfEWORkUJJ7_3w@mail.gmail.com> <CAJFbk7HJ1WA5Qc0LNEZpKgv78yiM0w7ex=gjgpjjTf3chhHhiQ@mail.gmail.com> <CANCZdfruoDPQE%2ByqebDomg8w7YKCkbFPvrPweJQUqoaOMN3rwA@mail.gmail.com> <1722758786.127406.1667909706281@localhost> <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com> <CAJFbk7GXw3pQxgcWfwYzVkF5ff=S8=oorRVJW5wY_6sEz81StQ@mail.gmail.com> <CAJFbk7G05iJgCADDJPPr-3qu8J9GcvS35aUOkWt5DC_UNcDYFA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 20, 2022, at 19:48, Archimedes Gaviola = <archimedes.gaviola@gmail.com> wrote: > On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola = <archimedes.gaviola@gmail.com> wrote: > On Wed, Nov 9, 2022 at 1:37 AM Mark Millard <marklmi@yahoo.com> wrote: > On Nov 8, 2022, at 04:15, Ronald Klop <ronald-lists@klop.ws> wrote: >=20 > > 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: = 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 > > =20 > . . . >=20 > Hi Mark, >=20 > As a recap on the kernel tunables, the changes are the following, >=20 > root@generic:~ # sysctl -a | grep oom > vm.pageout_oom_seq: 120 > vm.pfault_oom_wait: 10 FYI . . . As long as: vm.pfault_oom_attempts =3D=3D -1=20 vm.pfault_oom_wait is ignored. It also likely does nothing for: vm.pfault_oom_attempts =3D=3D 0 vm.pfault_oom_wait gets involved for: 0 < vm.pfault_oom_attempts . > vm.pfault_oom_attempts: -1 >=20 > With -j1 and -j2 options, both were able to complete the kernel and = buildworld compilation in 103 and 84 hours respectively. Though I still = could see messages on "swap_pager: indefinite wait buffer: bufobj" but = definitely it's ignorable as it survived the compilation process. With = the -j3 option, it failed along the course of compilation, it = encountered the previous error on "failed to reclaim memory" but this = time this error is not that relevant as -j1 and -j2 already works. = Preferably with -j2 as the appropriate choice for my RPi 3B build setup. Glad you got it working in your context. Thanks for the report. My media does not lead to the conditions and, so, does not lead to learning the behavior when "swap_pager: indefinite wait buffer: bufobj" is significantly involved (for the time scale of waits that you got into). The implication of the result is that you would need a larger vm.pageout_oom_seq value in order for -j3 to finish normally. Based on my media, I've never had to use larger values, but, I knew it was a technical possibility to need such. I do not know how to pre-calculate what value would work. (I'm not suggesting any more -j3 experiments.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?320C43A9-74FF-4848-9035-98BA1B71C44E>