Date: Fri, 15 Apr 2022 18:05:26 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd07@wayne47.com, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Can not build kernel on 1GB VM Message-ID: <61D59FF2-D8E5-417D-BA49-6E4A91D0C7D0@yahoo.com> In-Reply-To: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> References: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Dropped Mark J. form CC list.] On 2022-Apr-15, at 15:41, Mark Millard <marklmi@yahoo.com> wrote: > From: Michael Wayne <freebsd07_at_wayne47.com>=20 > Date: Fri, 15 Apr 2022 15:17:43 -0400 : >=20 >> On Fri, Apr 15, 2022 at 11:40:02AM -0700, Mark Millard wrote: >>> From: Michael Wayne <freebsd07_at_wayne47.com>=20 >>> Date: Fri, 15 Apr 2022 13:49:53 -0400 : >>>=20 >>>> I'm trying to upgrade the machine to 12.3 and having swap failures. >>=20 >> I reduced the swapspace back to 1 GB. It's only ever really hit = during=20 >> builds. >>=20 >> I set >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >>=20 >> There was no improvement. I still see processes getting killed due >> to no swap space despite only 7-8 MB being reported used. It sorta >> feels like it's not really able to use swap at all. >>=20 >> Note that everything worked fine on 11.x, this is a new issue on 12. >=20 >=20 > It is really unfortunate that the 3 or 4 conditions that > initiate the OOM kill activity are not reported as being the > specific initiator of the activity in 12.x . (Mostly fixed > in sufficiently modern contexts. 2 of the conditions are > very similar and tend to be treated as 1, leading to > 3 instead of 4. The other 2 have detail-specific wording > these days.) >=20 > I went looking back in time and 12.1-RELEASE-p3 has logic for > vm.pageout_oom_seq (2015) and vm.pfault_oom_attempts (2019-Sep) > from what I can tell. >=20 > If using vm.pageout_oom_seq=3D120 made it take longer before > the OOM activity, then further increases could be appropriate. > I've never had to use more than 120 but I know one person > used something like 1200 on a low-end arm Small Board Computer > (1 GiByte RAM, microsd card media in use for swap, as I > remember). I do not know that, say, 600 would not have worked, > however. >=20 > That vm.pfault_oom_attempts=3D-1 did not stop the issue should > eliminate "a thread waited too long to allocate a page" (modern > message) as I understand from looking at the code. That is > despite your report of: >=20 > QUOTE > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > END QUOTE >=20 > types of notices. >=20 > If vm.pageout_oom_seq=3D120 made no noticable increase in how > far things got (how long it ran) before the OOM activity, it > is possible that you reach one of the 2 conditions that are > treated as VM_OOM_SWAPZ. In such a case, either increasing > the RAM space available or doing kern.maxswzone tuning may > well be the only options to do the 12.3 build from the > existing 12.1-RELEASE-p3 context. >=20 > I've no hint to give for kern.maxswzone tuning. >=20 > There is the possibility of creating a 12.3 /boot/kernel/ > area from the likes of: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I'll be more expliict about my intent here, later below. > and possibly also creating/replacing the matching > /usr/lib/debug/boot/kernel/ debug information (if you keep > such): >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel-dbg= .txz >=20 > This would avoid the kernel build. >=20 > ( base.txz use is not as reasonable as it would replace > configuration files with default versions and the like. ) >=20 >=20 > I've CC'd Mark Johnston who has sometimes been able to help > with these types of problems and how to avoid/control them. > He is also the one that has improved the messaging in more > modern FreeBSD versions. >=20 > I include a reference to your original message for Mark J. > in case he has time to look, since the content has been > stripped in the message I'm replying to: >=20 > = https://lists.freebsd.org/archives/freebsd-hackers/2022-April/001018.html >=20 When I wrote about using: = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I was thinking of the following sort of sequence: A) Rename /boot/kernel so that you can revert to it. B) Establish a 12.3-RELEASE kernel.txz based 12.3 /boot/kernel/ . . . C) Boot that and then try building your variant of the 12.3 kernel. This would avoid involving any variant of the 12.1-RELEASE-p3 kernel in (C). If it went well, you could install and boot your variant. Otherwise, you would be able to report that the problem still exists for 12.3's kernel and could revert to your 12.1-RELEASE-p3 kernel if you wished. =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?61D59FF2-D8E5-417D-BA49-6E4A91D0C7D0>