From nobody Tue Nov 08 19:06:37 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 4N6Hdn3W8Dz4XFNL for ; Tue, 8 Nov 2022 19:06:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6Hdn0flKz4SsN for ; Tue, 8 Nov 2022 19:06:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667934410; bh=GedSb2NsewjZsjImkgZvrrH9W2d1hlA5UrXr3G1ve6s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZdxZPYVRmfkZuTWOZYG+BO4YtGfThrTircn3r71ZsqSKyrBv3fD/WZonMzfPIouEYWkcA4dSth+LUluknz5K3Idty+oqLiG5Z4XBAdizi2GLFY0XS9Yyse80gqmDKWY6Ma3WF9zOHj6R2b13HAVxXxUXVZo4mmxPcgkRN4q95iRbyoBQTA0ylrKQCXlRAfz5OaICsz6ubuVKCA7lemNXdTz1oVzgadaGIXqdQs9aRBILeUuTULXbdB0cj07cgxrmpCdMUPjnSIn1ApxHdvhkpw3JjwMMXwNWOWNJiHFyEjW2Rkb0rBUEYhk6ieXMuAcdI6FsxseGa69fRrhiPynCqQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667934410; bh=fL2aeqafHvUVZy07r1kZDMMfVLSxezjZUZEqgbd04Wl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uQ0KtHIHajH/WJYYBtTCee6Bc/rSf8ojQy+pFKtAwWOC6HL3aXq6/J0rX9vflybsIOebRHPxBbdPR3ik0kCehkpuNnHk3plqzjVtxCLe07uJN1OCQ57Yhh8eSFAapsSa8SBeBGKqp6VDUT4/4chrX840JpNFzwB9pGnEozDNmyHUYInoB2eHwfWKQ87nhPsG/iG2kVHWUqTfOfSkTRNX/3CcaMflHeZB+ykAJxptY4F4KudCh0Ve2Da6ZRDImxaWQkVm6RLVKbtSXiAEeRKanP8nB6v+jZtcggrYxcezG8zmHT2noY+ZiGUwoea4AYCGjZ2O79gs89Kofe2Ut8preA== X-YMail-OSG: RdJ2yDYVM1k4tz6p6v4Gt6l_bZp0Gg9Lcw7FuAq7kSEAnabR34dQQUBy838D66O pzG6Y0JmGDcJ5xKE7HQCQESYBynJUVmEJDrWpBaFoFq0xTV5skerEFzzrV0nqNNGsSdv1g.aSWgL XWF3vILMGPmE7RYn7MJG9vEhXpmNG9FWNQWd_TkT7HVnMKOP3w8xTVe._KNa6w4RT2UQp8elHiPE h9j.sRhKjrSN7.Nd3eq2hs9zl4SfruS4CjwdbCKojG9yCoxL7brJZNQsqP78uA74STrlf9cjSABH M0WEaCD8jKje_Pet7mVcZWyCsv7zUIOhyUQyGfsDXqg8Y2k_sorBcc3LeHJlehCUpbRr_SbMQcXN mGqt0jX5WqCDn2KxHTn1Y8XWvZSG9iBpLWqRSHcJj0GAmFxSmWBpAqIdsCscPl1VNI2.vCQHrJ0X A4DnMSq4RrzWA.j_bI8SUfepaLYS7QZcaqv9RrSkh_XzMVGfbQV6OFvFPZZNUmgm88HpF3XsLjU7 PInoCsaJMV6fE6oVJCWjOoJJGXA3lLTqy3WXEkuTfFYPko4aUmuk4dmwG.6De6ecD4Mp.k1jCfWI x6kT6aXImPjBrio2Or09pzP1HJvj5cad.o9KlVWR_tg3_1oVic917cdkbqjiZCHzlF.2eJ8aDVnl .MXkNdCVsp1npZLo9HiuwUktkp3cwBmg.7NaQ7ljMDAMdv4kut0QBhHwjOld_G4.2hsubwlcNOkO coHHYhWEnqqWL8yLZ.KzJYue.DxWgoFoQGGREPcsGfIQg1O7OdQ2Ln3VGyEmtdFQaDS26KkbKjDL qiAGDYL06meo6Ug7.CKtrkbhY7nAGpsOcGqqBuf4FB4wBOJ_g.mpzPCHGWOaTkRcoaU9dEJFt8uf qYAfQwHfgwRUWSIt4bEaj8oSORBs0nwVj4Q4cI5mSmriduExrRXdbcx4gCw5vMxsErGEye7djDAV cnILkzRb8aZjBzKfg_XU.Eb1N5AScW0fxmdFwvHt041T_zQ7ijbhaGNkuNnghMlIhkhN55dQePph aQl7tGVKiZ8MRVZnylazAOuNwwuN8Lwz.XVelpEHiCbXAFVC0An61msncF2xRzkqFfNUrdNGeNWB EfX0Vcb0rLt.w68yaCw9yIok8y.DFf1wR8IB1Idprj92NAbpL0HF.GPwKJNdk0q.3Swd6JjSIwz8 wxju2YfnujQQ_.vQv9lPyztnZxzLDsiHPiQG_s2LTzFEPNx1dAwzy855YRl4v2IpookrWLyCmZOM RArcYg4IKz3fbv8jV6tYIN3B4jq9ITx7cO_bv9ePlsIIuHhiEEPGuvvAnerKVh9bhOyfQVRDsrXI WRScENSc9Qnap0woE5o.Wj3QiZoehnH0hvyhrsoMFu9_osMfMgf3UkhYlcWy1Z7RdC0z8zLAhXx. c6k3cgT.5l.GJWmB8.DnR8u1HZU5GHXZ7Iw4rzes6cIH0AAYeX1nxOoEQc4Z67bO8nrkznQumFc5 AbN43bfo8vt7SJWyjXtfSLmW60CX.GJ59hcIexNKkbvh3497tlnsN1z18uLb8qvFixZGUkBjBKOS _RJwfwm4B2_9psmaW5SmdVM8k6dsi9IRPspXUeN5p_KoHLUnb0_UaEAw0UAZR4dIIXSio2g6Z1tF E2oUfeEmHWTTETQFjLzPGHpgvv.goohQbRpolZZJ_hUL04szvqeISrjk2GxkCnXffh2L2hlsdII4 4TuyjzavOziKdJhy_MqGOBLjQa2Q0_ocbK0kfPVHlythVRJmJq5w9I.JejKsC7Ednojv8TZ.2_HO 3oJPzcauxDBQNk1TwXL.0KWD5ss7ZmEKRSqBa0fWsEQP4GhqigGV0xENpg5lkwnISyKexP22YelR azo6wHbHvAJY487F7GMZFHOAHCBFPV8ydPRiv9Crsa1PavdGiKBQMD6QTnGZfCvGtIrhw.I5jMK3 jkFALgHNWSxwiFZuQAj3naZYq002QVSa01Tj51aiN.xkyCWFYKm5N1Vy5uLyNGPrUyVAtUjZsxcD ctMVRTfd9N_JulGaaTR1evhHeuc6iJ0tgBYZ2O4HPVeILZhHmrgL642rJLMrsaSP2crr616Qnpke 0iHur1sx.sHVBEUVmrvQ4XHJ9g3gdNrCgUKNH5CthBumFdUCuYT1JMaYX_2boyjBJUCamJ7dcn1w LPokckNsWPJmh6GbmPvX8eCjBnR2QpryhBFhxarnKSO_uuLc.40W7rzctVpbv8Mpwij3RgBsAaDr .tcpWOG1djZNRYwbbJEuUbGOT8t6Ko5HqSdkDFmRP.aYJf1HzzkPqZwEFEE.SSwf0NMlDnpb3WbX eX5FiXg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 19:06:50 +0000 Received: by hermes--production-gq1-579bc4bddd-6kwsn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5be59a664778f18de93b87b513e081f9; Tue, 08 Nov 2022 19:06:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: adding swap when expanding root filesystem From: Mark Millard In-Reply-To: <20221108174126.GA60338@www.zefox.net> Date: Tue, 8 Nov 2022 11:06:37 -0800 Cc: Mike Karels , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <981582E8-1CF3-46FE-B7CB-E3157205CE0A@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> <20221108174126.GA60338@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Rspamd-Queue-Id: 4N6Hdn0flKz4SsN 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:36647, ipnet:98.137.64.0/20, country:US] X-ThisMailContainsUnwantedMimeParts: N On Nov 8, 2022, at 09:41, bob prohaska 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 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? 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