Date: Fri, 3 Jul 2020 18:42:51 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Peter Jeremy <peter@rulingia.com>, freebsd-arm@freebsd.org Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <55D7CE27-DEA4-4F58-904A-D68D33845922@yahoo.com> In-Reply-To: <20200704011558.GA36886@www.zefox.net> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> <20200704011558.GA36886@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-3, at 18:15, bob prohaska <fbsd at www.zefox.net> wrote: > On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: >> >> The "every few minutes ... one core reaches 100%" implies that every few >> minutes one process manages to get hold of enough RAM to work through a >> compiling a file. That process then exits and all the RAM it was using >> returns to the free pool. >> > That's one point I was entirely missing. When the only runnable thread > finishes, nothing else can run till a working set has been swapped back > into ram. As Mark reminds me, at 2MB a second, it easily takes minutes > of doing nothing but reading swap to be able to run anything. Thus, > the long interval of seeming inactivity. Where you actually seeing a sustained 2 MiByte/sec rate over some significant amount of time during a "busy reading" activity? With paging/swapping being 4 KiByte random access I/O based (or some small multiple of that), I do not expect fast I/O from spinning-rust stye media. The amount of data that seems to be involved seems a bit much for drive-internal caching to well cover it. >> >> I don't think so. The default "run one build process per core" assumes >> that there's adequate RAM. It's really difficult for the build process >> to know how big a process will get, and so automatically cut back on the >> number of parallel processes it spawns. This is one case where I don't >> believe there is any alternative to manually specifying "-j1" or >> equivalent. >> > > In this case (essentially that of a batch job with no interactive use) > would using -j1 or -j2 reduce the overall compilation time? If I'm > understanding correctly the answer is "no", -j1 precludes using extra > cores when it's possible. From time to time it uses all four. The tradeoff structure is to complicated for me to predict specific time relationship. But I'd not be surprised to find that -j3 or -j2 would spend enough less time on paging/swapping I/O to end up using less overall time: higher fraction of the time able to work from RAM. To figure out the tradeoff's overall result would likely require experimenting/measuring the alternatives. Figuring out a better tradeoff combination for a tight-fit context such as this can be its own time-consuming activity. >> Note that Chromium is a massive chunk of code. A more normal build >> environment would be several dozen quite fast cores with around 3GB RAM >> per core. You are really stressing the VM system by trying to build it >> with ~256MB/core. >> > A smaller browser would be a very welcome discovery. So far, chromium > is the only one that has worked well enough to be useful. Not in my area of experience, I'm afraid. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55D7CE27-DEA4-4F58-904A-D68D33845922>