On Nov 20, 2022, at 19:48, Archimedes Gaviola <archimedes.gavi...@gmail.com> wrote:
> On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola > <archimedes.gavi...@gmail.com> wrote: > On Wed, Nov 9, 2022 at 1:37 AM Mark Millard <mark...@yahoo.com> wrote: > On Nov 8, 2022, at 04:15, Ronald Klop <ronald-li...@klop.ws> wrote: > > > Van: Warner Losh <i...@bsdimp.com> > > Datum: dinsdag, 8 november 2022 04:28 > > Aan: Archimedes Gaviola <archimedes.gavi...@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 > > > . . . > > Hi Mark, > > As a recap on the kernel tunables, the changes are the following, > > root@generic:~ # sysctl -a | grep oom > vm.pageout_oom_seq: 120 > vm.pfault_oom_wait: 10 FYI . . . As long as: vm.pfault_oom_attempts == -1 vm.pfault_oom_wait is ignored. It also likely does nothing for: vm.pfault_oom_attempts == 0 vm.pfault_oom_wait gets involved for: 0 < vm.pfault_oom_attempts . > vm.pfault_oom_attempts: -1 > > 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.) === Mark Millard marklmi at yahoo.com
