From nobody Sat Sep 09 00:43:48 2023 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 4RjDkc6TnBz4tH2S for ; Sat, 9 Sep 2023 00:44:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4RjDkc10ggz3SSB for ; Sat, 9 Sep 2023 00:44:08 +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=1694220246; bh=M9EdkE72+tJwWC0guQLuJLeQ5a0adys3ooqkO4r3EXo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Bl2V/ThTMSSqBBItmM859mTxKBT3w+NghYO/+Sizk+FoD8a2+4EYHUoTCzZ7SBZUeODiahpnuaMb8RAcnpJUZXBCmUmzqs0XEKP9Q1IR7/ocEx3gDILXzL22GQSjAv0WWsUHJfPqtijOy68VM4cASOvxsSdliCpzWZe1sTD8VpJ8mjFALEqAlApdgU9SnMxC+tvQ2bLXAQXS0eW0Gnf50QevI6sDWwPU+zeuWqbFOemCPMz4a3fOJysjSwu7XuT/9gS0h/jwRg89ndVkHYZpm2XEmQP0GhACYTE2YKQ0DcLD905O/RScwqQMGw0OnF8UzK7X6vkPXy06rYROAv1cjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1694220246; bh=UF9U8du64XGO2Gfd/U3c6qm1MlSggulj3B4KKwpIOdq=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TOQoa+FOWQBi77Jem2Lp+d74M8eS77idonin2JN62fv6ZU5s1/EI8XjCXheM7ggiWdOmXFPLS0Fks9mr4yslnXlg86Uld9/Rc+kmfgsNf9EUG1Xr+dvWIc/wMhrCjIKWRZJxmMAV9eXZv2UgPuEtTCh97kkh60UbWqoESN2PD57Mclabu2ctM0idwZVQOQJpsZUhPgFwePFX4vzUHCWbcVLCumV4iOrG3/qjiZ03PWL+iQ7bFGnJhryDfC9V1MFyqocLev2n8NPYiTyPbGOjz9qL9994mHUnXFhHWJJzoMDO+oGUN9I59xoaq8J3QOBvBjN6ABLZGmiTZ+NnvsyMeA== X-YMail-OSG: XbhwxLsVM1liVF7bpBKPPFwkniGw0ETEKgRnIxF8PmQe.NuKwwCo4wJNZyIM.ji cJ9UyPP6uNFcmEApWVBUo71hpGOkHpb3ztDTYaQG4v8PjINXd_0UBG73b4TP6iULkRFargL_wLQf TH3P.GGkd1BFa92.0wrFIQ1QQbu..3ZSLHVBUNl.coEf8XGXy8w.pixkVrvzum1995CSblNyCdEY M0bT11AfdaNVVwRDmeXLNu_UmojqznM3VulCDdwX9457GuZJK8jWjHTyVzQLUNPcyj.Y3cT34zQZ PrGwwTMZgeyXQ6cm1HeAeRUBs0rZGeQPeekqkxsSi4S_zoJ.oHoNRwckUVfWUhEHw3_ASv3X8lTr aHekJ_D7ic9lQ4Y211orGhmZ5SlYEYoov7pRKaJWPesx8yBkFjfKqmRmPly3A55LQcDnPSSa24UY gXF6ovEsQqfBOPsV8nakm60zwhtpVy7hcxgIkdib96qpA.2JU2M64Rvmg0TYfYscnpEnTm7Z.oi4 YZwfWyzzRosLBwMOA1IC_mG2NQA4VdfAArp76CgTULWDJzvsxP_yGu93WbHvLCI_brA_1GymvBHo U7osnehiPLkyCMI91xbqjjkz61m1G21zvERW80tjE0udO.cfE6U9O42UHiGQ6uChBWjsDqneF_B1 Fslinwv.75DOHrAbi1zmqQ6D3P0V4aQ0BVIuAhKFWCDmf897qpsEx1IZ0La59wLTOo.BdjV5KCi3 .tuKB0gkbuRxEDOaoQL.Nn3gETzWeQI.R82MWI_OsTCgw7qrG7NhMpgY5opbjUKV.F.fVsvMNcB8 mUStrwvIWwdrA7LIH1Rvl8gHigJZoWQt1U.njoO1Sxhi_zu2mL4f6Q37p6CXgulkxLFAJc6jeYQZ TvDEe_m1JthTN.lZpDbj8a.k.59fyWRZmYK3VPIlW4XSpnw4XgvjHL5DtwkC.LbKQy5gR5KBqwa4 Q0U2HY8EDF4d2Wcf9t4p_afGAY..sI.FwXuG4dzX0mhoCmfdwvKJAS9LNWmocaQISWa0qeF77aOy EcehJNVKY01OjNYPEh2OC.DGvmrGcge9gNe4J4kqGuzDRaD_KkYmLXpRWNuKtpwRdUe.0JN2j5Pg OAw0ZVk6sptAFzQpX7hrgfRk80LTh7fLYsF3xxmMe9sFc6E6tNg3X_6q.3AKrHVAfH9XJ9wk4ZAP nVht8EIlrKA1v8fa3dh8OFiAhC6Aeyn15U1UFoIP_KIa1_xsWkJaAjGyq23IZy5aIi4DfuvbltJ9 cO5l75kWqkFMpW0QPjgaCGKPbTfM5UHPhxx7CPfjnhUxDUlpk9WhPvzAi5YB_DGAypzZcnl_D6n5 f_51FRLH_XasmyVAgM8i5EdCJ0Vwmcj2vBydMewjKvcpurERVL0MAj.8iePyrP9SFiU6sQN4X5IX rzmpbu95taske_7HW3jGzMQfs72q9ma0v475o0vsvdJg_jey4lwQBj_rnzi1UL87iRNvlb2k8Jqm evkJnHMTAxzHt8zepBgdshpdg6oAhc0OfKsG5YTr5yrMZI9Myk8E0oPEMleanZ_QTH3496pmLEy0 VOabq33MEV8Cjpd7UUy25hTCIm8dau95tUtqHv47PunIXlN8T6ZRIl.x1siZ5mTq8JPf7EJUBqR6 FLg2JYhhtcf1MVQRrjXybaNSVBliYldI.HWfEaBNJbAvbAbN2FopdYPNTOJd9.NZ_wgONL6sEYq5 gh_bKY4l7sc.Cm.Ior3NRtJW4IlwWcsjphcg6GoPv51e0tQrPCoLeX3ri1s0z.IDIBHYYxWfrDTt Z_VXJGZCnC0kjML1o_Y2pL0wpPaFOHZaZE_KacCmYOUgJ.B1LwtM5dCu6uiGnszR2dn_WCHW2Yjq swzJDfqGMVXt9sqo8BEq2g7Igg.sYGPvQ7zwkS8onGBI341ANwv6JbESyJLvQZw7FwnErHM0ylda yaebhI_B6yR_3YFBgd03x6cK_K8boN9jnc1mqsgOqk4WKmdA5m2ep_XThbCyGPKIq2ln9tivfj0n k4GWcMu5viat91rem96LWt6Xl9vL6zFX3vEJPyvLhrMzZl.wezaRT.sr7XPFgC3wA87yLS_3sh0X hox3DM.vvqkmFNnHYL2AbW92UBPjh7.xF6aItdkIV1I7faAsbgrz.VVv..nuvLzE8kNi2zkJrQog my0b7Zz0uvRZlaFDFoSNvLgQU5ciTmQ0XOfoa0RDl7bJeFC6dbpN2qf.XLlAFAzQpQuQGkxPRqJy M3WovicaN4yq7YrEk4WAmc1gYTHMQQ0HZOWNnjPpVpJboNtZJnJ82N2S7nwT2fITbACwjf6K544P E_w-- X-Sonic-MF: X-Sonic-ID: a9f29f23-a245-4977-aef8-a4f9ff81b4d7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Sep 2023 00:44:06 +0000 Received: by hermes--production-bf1-865889d799-k5x9p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43077e66413c5caca61090508e182ef5; Sat, 09 Sep 2023 00:44:01 +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.700.6\)) Subject: Re: High swap use building Kyuafile on Pi3 From: Mark Millard In-Reply-To: Date: Fri, 8 Sep 2023 17:43:48 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3815402A-CAC0-4299-BDC8-153E9C71FCDC@yahoo.com> References: <5DD3836C-E6F1-4EB5-8F11-3C342A5915DF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) 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-Rspamd-Queue-Id: 4RjDkc10ggz3SSB On Sep 8, 2023, at 16:42, bob prohaska wrote: > On Fri, Sep 08, 2023 at 01:32:06PM -0700, Mark Millard wrote: >> On Sep 8, 2023, at 10:58, Mark Millard wrote: >>=20 >>> On Sep 8, 2023, at 09:14, bob prohaska wrote: >>>=20 >>>> While building a -current world on Pi3 using -DWITH_META_MODE it = appears that >>>> swap use is quite heavy (~2GB) well after clang finishes compiling.=20= >>>>=20 >>>> The tail of the build log shows=20 >>>> Building = /usr/obj/usr/src/arm64.aarch64/lib/googletest/tests/gmock_main/Kyuafile >>>> as the last entry, suggesting something in tests is the cause. >>>>=20 >>>> The machine reports >>>> FreeBSD pelorus.zefox.org 15.0-CURRENT FreeBSD 15.0-CURRENT aarch64 = 1500000 #49 main-n265134-4a9cd9fc22d7: Mon Sep 4 10:08:30 PDT 2023 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >>>>=20 >>>> The build command is >>>> make -j3 -DWITH_META_MODE buildworld > buildworld.log >>>=20 >>> So up to 3 builders can be active at the same time. >>> You seem to have described only 1 builder's activity. >>>=20 >>> Was it the only active builder? If other builders were >>> active at the time you also need to check on what they >>> were doing. The ~2GB is the total across all activity, >>> including the (up to) 3 builders. >>>=20 >>> A command that would show the active builders would be: >>>=20 >>> # poudriere status -b >=20 > I'm lost at this point. No poudriere use is involved, Gack, I substituted the wrong context. Sorry. No poudriere details that I referenced apply. > it's > simply a -j3 buildworld in the "building everything" phase. However, buildworld and buildkernel with -jN do parallel build activities (for example, parallel compiles/links), with up to N at a time. Do you know how many and which commands it was as the time: 1, 2, or 3 active for a sustained, overlapping time (if more than 1)? > Normally swap use peaks while building clang and then > diminishes markedly in the building everything stage. I'll remind of history when a google test build step used to prevent your builds until they changed the optimization level down to avoid the memory-space resource use. LLVM related build activity is likely to have the major duration for notable memory-space use. But it need not be the only example of notable memory space use overall. I'll also note that the early LLVM activity is library code and later the actual compiler, linker, and llbd are built (using the library code to do so). These activites are likely of shorter duration than the library activity, but that need not mean much about the memory-space usage peak. > Previously, by then a -j3 build isn't swap-bound. Monitoring for what is running during the ~2BG swapspace use would be appropriate. top sorting in some appropriate order may give a clue, for example. More detail about what would seem to be needed. > Buildworld was still running, with three jobs, two of which > were over 1GB each in total size, though the RES numbers=20 > totaled only about 700 MB IIRC.=20 What were each of the 3 jobs doing over the time frame leading to and spanning the ~2GB? (I assume USE_TMPFS=3Dno and other avoidance of having tmpfs competing for RAM, for example.) RPi3B variant: so 1 GiByte of RAM or so. 2 GiByte of swapspace or so used. (1+2) GiByte of RAM+SWAP or so (based on the little detail I have). RAM is actually not all available, so on the low side overall. The kernel and other processes use RAM too. RES only tells you (incomplete) information related to the RAM part of RAM+SWAP. Note that, say there was only the 3 jobs and the kernel: 3 GiByte/4 is about 750 MiByte RAM+SWAP for a mean. You indicate two possibly 1 GB jobs, so that might total to 512 MiByte more than the mean scaled to 2 jobs. The figures do not suggest vastly less than ~2GB of swap space use for the whole system. It still suggests the original reporting over focused on one job, apparently one with the command already completed. A more overall span likely is required evidence, possibly across time leading to and during the ~2GB as well. =3D=3D=3D Mark Millard marklmi at yahoo.com