From owner-freebsd-arm@freebsd.org Fri Jul 3 23:40:03 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E70335C30A for ; Fri, 3 Jul 2020 23:40:03 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zBJy0JfFz3ddC for ; Fri, 3 Jul 2020 23:40:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 063NdjFg098100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Jul 2020 09:39:50 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 063NdcMH020332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jul 2020 09:39:38 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 063Ndcwo020331; Sat, 4 Jul 2020 09:39:38 +1000 (AEST) (envelope-from peter) Date: Sat, 4 Jul 2020 09:39:38 +1000 From: Peter Jeremy To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200703233938.GB30039@server.rulingia.com> References: <20200703224433.GA36511@www.zefox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20200703224433.GA36511@www.zefox.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 49zBJy0JfFz3ddC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-4.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.016]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.016]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.35)[-0.345]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 23:40:03 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jul-03 15:44:33 -0700, bob prohaska wrote: >In watching wwwchromium (very) slowly compile on a Pi3 running >r362742-current something strange showed up: It had half a gig=20 >of "free" memory, but still has over a gig of swap in use. "Swap in use" relates to memory that has been pushed out to the swap device and not referenced since. There can be both lots of swap used and lots of free memory if the system has been under memory pressure (eg a large process) in the past but isn't now. The system will not move data from swap back into RAM unless it's referenced. A typical FreeBSD system will have lots of mostly idle processes and it's fairly normal for them to get paged out. > The swap device is saturated. > >Here's snippet of top output: > >last pid: 77187; load averages: 0.56, 0.80, 0.82 up = 4+19:29:15 14:39:56 >39 processes: 1 running, 38 sleeping >CPU: 0.1% user, 0.0% nice, 0.2% system, 0.1% interrupt, 99.6% idle >Mem: 80M Active, 63M Inact, 3508K Laundry, 176M Wired, 97M Buf, 580M Free >Swap: 3547M Total, 1341M Used, 2206M Free, 37% Inuse, 1188K In That shows page in only - so the system is trying to get data out of swap to fill the free memory. And >1MBps means it's not stuck. >It isn't entirely stuck, every few minutes free memory wanders down to=20 >20MB and one core reaches 100% use, but in general it seems to keep >considerable free memory in preference to reducing swap use. That would >seem to be unhelpful in this use case. =20 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. >Obviously it's possible to use -j or MAX_JOBS_NUMBER, but reluctance to >keep all memory in use makes me wonder if something else is amiss. 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. 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. No. =20 >Looking at man tuning revealed nothing I recognized as relevant.=20 > >Thanks for reading! > >bob prohaska > >_______________________________________________ >freebsd-arm@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arm >To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Peter Jeremy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl7/wa9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLKfQA/+JATJK6hQSEq2hLAH+dWaNfdDh8ML6ivc5KTlFJAuBtl0x5Mi3x1qu74z 9cYroDwJJIfjLRS28allmf9NPMKLlx0OXNSVnieF2eNglJaH9Pk9wWwJDdn28rYK k/quWwFUVCZaMO7KQhwFrWKBKMGCna+OMgu9mX4TKA1SdmBpy45QDHBwbubl+m18 TdkMbkZCgEEunAUFwLrpW55W5FD+GWzNsXMbcGs/YlqBNzBHPhsjKTp1OR57Xd2L +8xhGMPodWoT08DW4mGbyI53hbvTdIQkUyZjhgHrFy5hhHOQN80WjgKyUrXBRCBD ldMsei9Jn6E4rd5FzVgX7XVIAR4q9u0ih4ZlQ/l52XaqItMcbYc970XHo/bqjINP nUXEfz1syWs8ZxXCgtXDEVeI3dwnVoPzg5flIWbnH3lW9jsz8NAtZ6/tCAz7XfGU R7rJ3KhgATQdOKuYgcXyYWvXlq88hW3ymNrm/oIDj84aKIBkwapQ3nosvzwoJfRo kLuEoere9om0amVeSAR6xX5ENsK/NScR9jEd5NAMBW10IgxJj6P/qYA7MwpaPIYy iVOw3Q+K6Y8gjWVRBYs7eYY/rkeHkstW2pKUNT2IU3O3PBxXP1dXeucQYRJSJ1Dz gyKo5oPabQuBfohvEOKMu34cHP+7FZ17Qn5YL26pF94ID5Z4xs0= =h6NF -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--