On Mon, Nov 21, 2022 at 12:24 PM Mark Millard <mark...@yahoo.com> wrote:
> 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 > Hi, > > 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 . > Okay, noted on this. > > > 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. I too am glad about the outcome of the testing. In the context of -j1 and -j2 build options, the oom kernel tunable settings were very effective. Thanks a lot for your help! > 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). > Ah okay, as you are using a more powerful media so there's no manifestation of such messages. Nice and good to know. > > The implication of the result is that you would > need a larger vm.pageout_oom_seq value in order > for -j3 to finish normally. Oh I see I will take note of this one. Thanks for the further hint! I can explore this soon. > 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.) > It's alright, if I have spare time I will explore the -j3 settings further. For now -j2 is sufficient. To Warner and Ronald, thanks as well to your inputs! Best regards, Archimedes > > === > Mark Millard > marklmi at yahoo.com > >
