Date: Tue, 17 May 2022 14:10:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: Michael Wayne <freebsd07@wayne47.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Can not build kernel on 1GB VM Message-ID: <84F2341A-C7AF-41F3-8A69-70FB9D7271CF@yahoo.com> In-Reply-To: <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com> References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> <20220517135616.GA72471@post.wayne47.com> <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-May-17, at 12:40, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-May-17, at 06:56, Michael Wayne <freebsd07@wayne47.com> wrote: >=20 >> On Mon, May 16, 2022 at 12:07:18PM -0700, Mark Millard wrote: >>> On 2022-May-16, at 07:37, Michael Wayne <freebsd07@wayne47.com> = wrote: >>>=20 >>>> More info. I am running UFS so the ZFS should not be an issue >>>>=20 >>>> % pstat -s >>>> Device 1K-blocks Used Avail Capacity >>>> /dev/md99 1048576 0 1048576 0% >>>=20 >>> That may well explain some (or all?) of what is going on: >>> file-system/vnode backed swap spaces are subject to deadlocks. >>=20 >>=20 >>> Which suggested patch(s)? Any patches for . . . >>=20 >> This one line change (patch reduced to only relevant info) that >> was posted earlier on the list. >> --- a/sys/vm/vm_pageout.c >> +++ b/sys/vm/vm_pageout.c >> @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) >> - if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed = + 1, >> + if (target =3D=3D 0 && ndirty * = isqrt(howmany(nfreed, >=20 > Why my brain was stuck on "patches for messaging better" > I do not know. Seems obvious now that you show it. > Sorry for the noise. >=20 >>> Can you switch to using a swap partition instead of >>> file-system/vnode backed swap space? >>=20 >> AFAICT, this would require a reinstall as there's no easy way to=20 >> shrink the existing image.=20 >=20 > You may ultimately have a requirement that the image > containing the UFS file system and swap space be no > more than some specific size), implying that the UFS > file system would need to shrink to make room. >=20 > But, for testing, could a copy of the image file for > the VM be made and then be grown larger and then a > freebsd-swap partition added in it for use as a swap > space? Then: switch to using the partition to see what > happens? At least we might learn if the issue by > itself is sufficient to avoid the problem you are > having. >=20 > 18.3 "Resizing and Growing Disks" in: >=20 > https://docs.freebsd.org/en/books/handbook/disks/ >=20 > has notes some notes about doing such growing and > mentions virtual machines --but uses an ada0 > example. It includes adding a swap partition. >=20 > It may be best for such a test to have a larger > than intended swap space as an initial test and > then, if things work, to change the swap partition > to be smaller and see if it still works, possibly > bisecting to find what an approximate minimum > size is and then judging what to use from that. >=20 > (Either way, relative to avoid the existing problem > that you are having, based on my experiences, I would > never recommend file-system/vnode based swap spaces > be used.) >=20 >> Summary of events to date: >> - This was installed as a lightweight machine. It will never hit swap = in >> "normal" operation. >=20 > The toolchain's memory use has been growing as the > versions progress. Fixed RAM+SWAP sizes over long > periods of time are not realistic as stands --unless > room was provided for growth up front. Because of > kernel data structure tradeoffs, SWAP sizing is > effectively constrained by RAM size. For 64-bit > contexts, something like 3.8*RAM avoids notices > of mistuning when the swap is added. >=20 > (An unfortunate property of the mistuning-message > is it makes a suggestion that involves other > tradeoffs for other kernel resources as I understand > --without giving any hint that such a tradeoff is > involved.) >=20 >> - The only reason I added a swap file was that someplace in 11.x = building >> the kernel ran out of memory. >=20 > Toolchain again, yep. >=20 >> - I only build a custom kernel to get options TCP_SIGNATURE for bird. >=20 > Any chance that you could build the kernel outside the > specific VM (in a less constrained context) and somehow > transfer it into the VM? >=20 >> - The swap file worked correctly for all of 11.x until I tried to = build 12.x. >=20 > file-system/vnode backed swap spaces do not fail on > every use but are unreliable. Back when I was isolating > the failures that I was seeing, I found notes from > a wide range of time frames from folks having problems, > as I remember. (Not that I could point you at them any > more.) The problem did not seem to be new, predating 11 > for sure. >=20 > The toolchain memory usage growth over time has probably > lead to reaching failure for file-system backed swap > spaces ever more often over time for ever less > constrained contexts. >=20 >> - There likely out to be a FAQ or handbook page about how to lay >> out lightweight machines. Having used it since 4.x, 1 GB "seems" like >> a pretty big machine, yet these issues arose. >=20 > If partition based swap spaces prove insufficient, > it may require adding messaging to the kernel that > reports on just which of the 4 conditions is > leading to the kills --and possibly related > information for the one that is happening. That > context might be required to make progress. >=20 >=20 I'll note an old buzilla about OOM kills: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241048 started on 2910-Oct-04. [12.1-RELEASE was released on 2019-Nov-04 --and ended support on 2021-Jan-31.] The bugzilla was resolved as fixed on 2020-07-11, but the criteria is a little indirect and your case might well have prevented such a classification if it was known back then. (Too late now for 12.1-RELEASE-p* .) If you still can, may be it is better to skip having 12.1-RELEASE involved in the upgrade sequence? =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?84F2341A-C7AF-41F3-8A69-70FB9D7271CF>