Date: Tue, 8 Nov 2022 09:41:26 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Mike Karels <mike@karels.net>, freebsd-arm@freebsd.org Subject: Re: adding swap when expanding root filesystem Message-ID: <20221108174126.GA60338@www.zefox.net> In-Reply-To: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com> References: <202211071610.2A7GAcHl090048@mail.karels.net> <20221107175206.GA49113@www.zefox.net> <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net> <20221107205150.GA53784@www.zefox.net> <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com> <20221108043817.GA55121@www.zefox.net> <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[much snippage ensues, hope I've preserved enough context] On Mon, Nov 07, 2022 at 11:05:16PM -0800, Mark Millard wrote: > On Nov 7, 2022, at 20:38, bob prohaska <fbsd@www.zefox.net> wrote: > > > On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote: > >> On Nov 7, 2022, at 12:51, bob prohaska <fbsd@www.zefox.net> wrote: > >> > >>> . . . > > > >> Also the amount of space > >> U-Boot and the like takes varies. The Rock64 images > >> use a 16 MiByte space for its U-Boot and the like, > >> which are stored outside any file system. > > > > I'm not sure how anything can be stored "outside any > > filesystem". Might it be better to say "in a private filesystem", > > as in not known to the running kernel? > > > The 2 dd commands above put the content of idbloader.img > and of u-boot.itb into the so-called "free" space > indicated, at very particular positions. > If there's no guide to what's free vs in-use, there's no filesystem? I see your point, but then the msdos partition is a filesystem. Thus, at least on a Pi, nothing is outside the filesystem. The Rock64 case resembles the boot blocks of a DOS boot disk. Am I reading right? > > Is there any basic problem with automatically establishing a > > swap partition during a microSD card setup? A trio of self- > > hosted armv7 Pi2's with swap on microSD have been running > > happily for over two years as name, mail and webservers on > > 64 GB cards. Admittely, aarch64 is a lot more swap-intensive, > > but a Pi3 ran for about a year on a 128 GB card before things > > started going wrong. That Pi3 was running buildworld > > most of the time. > > Are you asking for someone to give such support > to each of the following contexts (ignoring > u-boot-master and u-boot-tools and the like > that also show up in the list)? > I'm a bit confused here, as the connection between u-boot and swap availability isn't obvious to me. > # ls -dC1 /usr/ports/sysutils/u-boot-* > /usr/ports/sysutils/u-boot-a13-olinuxino > /usr/ports/sysutils/u-boot-a64-olinuxino > /usr/ports/sysutils/u-boot-bananapi > /usr/ports/sysutils/u-boot-bananapim2 > /usr/ports/sysutils/u-boot-beaglebone [many more examples snipped] > > What fraction of what size user base actually does large > port builds and buildworld buildkernel or the like on > each of these [or otherwise needs swap space in order to > have enough memory space (not just RAM)]. If the > volunteer(s) that provide this context have no interest > in doing such activities on such hardware, how likely is > it that they are going to provide the more involved setup? > I simply don't know. Those with a loftier viewpoint probably do. Projects like FreeBSD have to pick and choose what they support and not all platforms are equal. I suppose one would seek to balance benefits, burdens and breakage. For something like Raspberry Pi the benefits are obvious, breakage looks small. Burden on the project is un-gaugeable by me. As one of the cheapest SBCs the potential user base looks large, perhaps the largest among the many competitors. > > > > Configuring swap manually on a RPi microSD system is a very > > considerable amount of work. > > That might contribute to what the volunteer(s) choose to do > or not do. Perhaps that is what motivated the automatic swap creation idea. > > > Having it happen by default > > wastes at most a few percent of the card capacity. > > Presuming large enough capacities. 3.5 GiBytes would be > more than 10% of 32 GiBytes, for example. What is the > distribution of media sizes for folks that do not do > large port builds or buildworld buildkernel on such > systems --but do use such systems in some way? What > fraction of the overall use of such systems is that > set of folks? > The original proposal set a minimum amount of free space on the card before attempting swap creation. That would seem to solve the problem, unless I'm missing something. As a practical matter 32GB is a small card, 128 readily available and cheap, 1TB expensive and available. > > At this > > point I can't see any reason to say it's a bad idea and > > have some personal experience to suggest it's a good idea. > > Getting someone else to be interested in doing what > you would find useful can be a challenge. Nothing > about that requires that the idea be a bad idea. Did you mean "good idea"? If so I agree. "Good ideas" for one are mere distractions for most. > There are far too many good ideas for various context(s) > to implement them all for all the spanned contexts. Very true. That's why I suggest looking at benefits, breakage and burden of support. Knowing that balance one can decide if the user base is big enough to warrant adoption. > > > [bsdinstall limitations snipped] > > > > It might be worth mentioning the /boot/loader.conf and > > /etc/sysctl.conf additions you've mentioned in other threads, > > as adjuncts to having autoconfigured swap on microSD. They've > > all been helpful in my experiments on RPi2 and RPi3. I think > > they'd be constructive additions to the RPi images and perhaps > > others.. > > > > Mostly, these things go back to what we learned from markj > primarily (vm.pageout_oom_seq) and kib primarily > (vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming > that I remember which-for-what accurately. Using > vm.swap_enabled and vm.swap_idle_enabled to avoid a form > of losing communication with the system(s) when they are > using the swap/paging space is more recent. > I didn't catch on until you made the importance explcit. All apply to the constrained-memory situations in which automatic swap creation is likely to be important. It might make sense to bundle the settings if practical. Thanks for reading, and your insights! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221108174126.GA60338>