From nobody Tue Nov 08 17:41:26 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6Fl95v4vz4V0CS for ; Tue, 8 Nov 2022 17:41:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6Fl92HrLz4DXW for ; Tue, 8 Nov 2022 17:41:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2A8HfR5H060758 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Nov 2022 09:41:27 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2A8HfREe060757; Tue, 8 Nov 2022 09:41:27 -0800 (PST) (envelope-from fbsd) Date: Tue, 8 Nov 2022 09:41:26 -0800 From: bob prohaska To: Mark Millard Cc: Mike Karels , freebsd-arm@freebsd.org Subject: Re: adding swap when expanding root filesystem Message-ID: <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> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com> X-Rspamd-Queue-Id: 4N6Fl92HrLz4DXW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-ThisMailContainsUnwantedMimeParts: N [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 wrote: > > > On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote: > >> On Nov 7, 2022, at 12:51, bob prohaska 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