Date: Mon, 13 Aug 2018 21:38:04 -0700 From: John Kennedy <warlock@phouka.net> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, Mark Johnston <markj@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180814043804.GE81324@phouka1.phouka.net> In-Reply-To: <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <B81E53A9-459E-4489-883B-24175B87D049@yahoo.com> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <FC0798A1-C805-4096-9EB1-15E3F854F729@yahoo.com> <20180813185350.GA47132@www.zefox.net> <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
First off Mark, well said. It's a pity to edit so much of it out. On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > Here there is architecture choice and goals/primary contexts. FreeBSD is > never likely to primarily target anything with a workload like buildworld > buildkernel on hardware like rpi3's and rpi2 V1.1's and Pine64+ 2GB's and so on. It's masochistic, but I think it's important to be able to recompile the FreeBSD platform. It's independent, it's standalone, and it doesn't depend on something else to give it life. I remember when BSD and it's predecessors ran on a lot less power than a RPI. Of course, everything was smaller then. You can pry my nice, modern computer with fast CPUs and fast disk out of my cold dead hands though. (: > And if things were still like gcc 4.2.1 for what it takes to build the > toolchain, this likely would not have been noticed on such hardware. The big > change has been what it takes to build the toolchain instance(s) that other > stages of buildworld buildkernel use. That is the change in the workload that > requires changes in the likes of vm.pageout_oom_seq for buildworld > buildkernel --or just finding a -jN figure that avoids leading to Low Free > RAM for the environment(when possible). I've been running vmstat in a loop during the whole build process (haven't finished a whole run yet). With 1G, I'm sort of begrudging ntpd it's 18M of resident RAM, but the top-5 and only running processes are by far and large the build processes (as sorted by resident memory). As you note, looking to have as much free RAM as possible (paging, not swapping since long delays in swread means I'm not crunching code). This run is -j4, and I expect I'll try a -j3 for the "fun" of it. As you note, doing some swapping isn't bad, as long as I'm not wasting so much time that my workload would run faster with -j3 and more RAM being available. It's true that a RPI is not my choice for disk-I/O workloads. And not enough RAM to keep it there, either but it's way better than some. I'd love to have a whole host of little IoT RPIs running FreeBSD if I wouldn't want to patch them all the time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180814043804.GE81324>