Date: Tue, 8 Nov 2022 11:06:37 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mike Karels <mike@karels.net>, freebsd-arm@freebsd.org Subject: Re: adding swap when expanding root filesystem Message-ID: <981582E8-1CF3-46FE-B7CB-E3157205CE0A@yahoo.com> In-Reply-To: <20221108174126.GA60338@www.zefox.net> 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> <20221108174126.GA60338@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 8, 2022, at 09:41, bob prohaska <fbsd@www.zefox.net> wrote: > [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? The older RPi*'s are unusual in being just file system based. (RPi4B's and the like have the EEPROM updatable as well but are otherwise just file system based.) DOS boot blocks were more standardized, if I understand 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. Are you after media that boots without being adjusted? That would make the U-Boot issues (and more) part of the overall activity of making media images available for whatever range of devices you are after. One image does not cover all those cases, possibly even if U-Boot or such has to be manually added (presuming some support of GPT anyway). >> # 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. You are already seeing the judgments in the support that is available now vs. not. Part of this is the overall difficulty of supporting the RPi*'s, making efforts in other areas for them less likely. (And, are you really only asking for the RPi*'s?) Do not confuse the RPi* general market and the realtively tiny RPi* with FreeBSD on it subset. Or, going the other way, the size of the FreeBSD installation base overall vs. how much of it is on RPi*'s. (It is less obvious to me for aarch64 RPi* vs. other aarch64, for example.) And then: The size of the set of those doing large builds or other needs-swap-space activity on RPi3B class aarch64? At some point, FreeBSD ends up with "beyond here is self support". >>> 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. But volunteers would be biased to avoiding dealing with complication of providing the automatic swap creation unless they had other reasons for doing so. Your motivation to hope that someone implements such for you and others and the implementor's motivations need not be the same. You can likely infer that the folks that would do such activity have not found that it is a big deal for their own activities. If it was, they likely would have already provided such to support their own activities. >> >>> 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. So growfs to less than the space available, then add a swap slice/paritition, but with checks for "would not fit well" and handling such cases? >>> 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. Just because you might not get someone interested does not mean an idea is bad. That was the intention of the wording. >> 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. I think you are already seeing the relative priorities people have judged in what has and has not been done. Some of it is just "working in this area overall is too painful compared to other things I can work on". >>> [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. So you are really after pre-supplied images configured for "constrained-memory situations", at least on RPi*'s with 1 GiByte of RAM, with updates as releng/*.* , stable/* , and main progress? I'll remind that, as far as I know, no one is actively working on RPi* support in the FreeBSD code. That is why FreeBSD requires versions of RPi* firmware that are over a year out of date, for example. So far as I know, any new RPi* type of device requiring more recent firmware would just not be supported at all. (I'm not aware of important reasons for firmware updates for what the firmware required now if new devices are not considered. But others may be aware of reasons for such.) === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?981582E8-1CF3-46FE-B7CB-E3157205CE0A>