From nobody Sat May 22 20:12:23 2021 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 3A2408D5DEF for ; Sat, 22 May 2021 20:12:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FnZQN6rLhz3sr0 for ; Sat, 22 May 2021 20:12:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621714346; bh=j2RCrJR9f61jdZ4i53+wJsJPPp40SSljb4MuM4Si99w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eFXd7aURXK6FDFLDvQsjyuoS5T4ZiirCsBBYkahNl4wEe6xKw+ebiqbJWixnN3nnoxOI1BHHWYTZwEBxnqj2jJVg0wjmGxIGoIDMnV+9nNrpqzLhBzHoz8Dsarh3F9jd5gSBJmsrR5DiH0RohWP/loeXUhhRhfzPdR4Uv/f7nkVEzeTRXyKPUIMG1GG8KJ7hDkHEZNs0Kjq4dtT8ng805aMT+0ryGbf1lU5WE7Sg/W7D3F8XWmPwpbR8Q8bxRDVHNbc5XM0sPs2cWiex7zxCjm0BQoXtJ0NpkP+qWgBTkQAPtrP5n9w3RaP3s714vekzw4Mb8PCq3/P12rGHkHoYPg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621714346; bh=KYt0VyAhzLTbEuQ47umMG9wByPzQNxWN2afgoe50gJ7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Xkegx2hn5omLAOt6tPsjN10i5Zc/mdTq/j4oKCB20qC0CBeQvelCov+sTqQbzwS5y1UxB0ckkp9X1ZHYWb2Pox0mWbbtk4elTqpSBfsrkBvakGAusPKaBUZvktruGY3egLK0KnQu5FpeMoftOc9ZfBe92Hw2bgRxr4DMw5rwNkGx5n4d2+hMnsg8rwJdG5XnEJY0J966+j4Ja64i9bEQGdAttfzkp9chgxAwwe+2UuXO/BNskBn0o/Y5p0zLHAFuu36NwZ3xe1iIZNCLMiWAqNrUHeWnFkdsY3KP3DX9A4/gkmzX6Hm+yVRXgocLPzAeA+brNnfNqNUaAxRpxkJyJg== X-YMail-OSG: Omu02e8VM1lIBRE.ztaBsnEmGq7VIHTl.GD0ANQK0j0Z7XZrnDvk_6hIvK9FF84 EOUonpqHC2Vqnel07g3RqYN.JLidSLxrfozB8_5qmJYruj0NZJ8d7ywue2EF97Z7ia5B0LrRt5lY wchoBlE4uIbZAGMSTxOmED1LSpIOp4OMzsm2L9pDB9rmBEkDDCwSr0joAHtAi_BtmlUhf0iNkvzz uYAnWpZE7Skh5mGRy6ZBz6A9I_Fs9OXLUS8QaONof62Z07Ps9kIOJDcCZ7etLrjhQ.X1IPLKyyqR d2fyfwh_.8jHV.k4lidX_WNw.NXEaD5vY7dhTTda4Sd9Cp6EzO7zzpjzY6SA4ZOzs0uWyJSMRwL9 fBkuVgjACaz9fwOs5IjwS5uO5OnNuYfMlZ9V6mByaZQBe2o8aj._3VTC._8HIc4NjJMNLM2xQDEm IxIA6S9TrgAjsRiRbErNPNtLOSP07I7NBAzTlgFml0rzif1nfa673WLUva9oKyVFS1BmH4E7KfNW Y1x0iZyQDI6IGkFVf2rXQoVgiqruXp.NCmU3_3OusJPm7jpWQ2n0opSpIk20dF_nmhugnjAkejmY 3XYFAfadwcYosl4mg9UlB2i91caRVVknx91c30EjF8vQo41pd5hw3Q4rm3t_fGxMvSJDJpI_DA.Q nUxxFuuepnwIjTrKHYM4r022XVIFmEsd9NcmEA1XLEUFCvVStf_0qgbYUI1beXYpm3mjmHoIxX1d uwfVXB67cPdIBIbu6BTx0wIZ6BqQ5reo1myt5IINHtVg8TJVGHoFhM0N1mpLkjZWc.p23u5v9cza vB25u6lO942qY3YREbYQJ2kjPQEyJSSqQ.JGAU7XjnQJcM17BZJhEze_5xLT4tVkJzx8GqFcpEBZ FZ.gOdBQtL9NEFtJ8tlkze2aE9W6T9LoSzqmIr3JKQ2f3EKqSZjuVXXRNQzuXG4gJXMT1tkeIwQX LC6JUVDEDeBLkfa6Kwv53K9esDvqXC_vCEavZVTwGsxRk.SfzqhevdhCcvCJfrmfyNV9FOVNkzPg la4OBU_ENAUP9yRFvJOWQLVsq48XV3Kvc9_kI6dTmozZdVb00ZVtfvj2gG_exfFUpcKTKcDsYbr. LkZc7ZvSHqFnt_BjM37PPaDk5ffq8KtgefmItIuIOIXVlrHwbvjWD.iw08zTuPjMhU8snCPupoyh 6FDypDSgEuV0L7zQRP3STdA6WCCGvVnCXRYOqyqshvU.kkGdXHEBq9RPjtsFKIo37FhD1yhefne4 PcS8XMNQahuofOMen_1EjSPoXxeT92u3PEwru2.oqz1BNc8yBZilz4uUKDMVIxzC3Gc1Bpakk3TC MRnbqj7rDWASZiHiLtGG385xubPGdeeKH_x1V5bRy9S4r898nmkRFktu_u90BHv1ABmQD9SvyDVy r1X6jQr6BR8XHmSy9B_Fv7Hpxy2SZ7BZ2OkLGwmIQyp9vlt8nFmvdLKA7590jwasbsNSKilA0Sy_ RG_QucAlFbqTfW1TOgfziVynLzcskn7zJd9.QWr4aMuRw6qRqrzcSkyo3GCzNnNWYUQn3SumdNvi y0F4npT7KGh4MXFYb4RbD_edGgCbyqYy3poy8JdGaIfjEZ1I6nlGral23_pOjOWsfaXXTI6QR_j3 _nuehi4Tz5ZqLxLc2SU0RbJfVeYNPSRzXHqisKXvLqjaHCxh2dIQZvpRIfQp036vNbEAj99aW9wx .c1DpOqvvLQHubg8FHXmLejU0JYFlnD85dD0fqVdheiHwxQLBLyzSWH98n8mkwHmWO5goTi6YDBs KM0X5nS8rpnAz4p2MMDeh7VTluw21TwdF9Za21HiwKIWKl20jpP1kOeKUsQZX5zkHAT0naCOtGEu WrVhJ1RgvZGThB5_RcsRyOwAuCguxo11vCelp1gFb18GLPa9zEcEGGDI.1N6NhN85GJ1kR.gFJcq EfyDz1EOHwzPq8qA0.lnWJVpVPIsBB71Ol5PBZVUS0sV4n6u9RdduedQyXp81mZgEMCh22LAdIGq QyOK5Pjz088DwaMZUEJlPrWnfaidc65h.dhx7A7wWY0R0ns9mMf2IaLD5UTjUoteLv4.CJKpJqj9 cHWZvrNANrQUbVq4.bzrqUxxY9Dg6aGvNMkOlV9lOMipb9_vLNjzYdPMNKvc8w2J3W_uEgMGzHCi d53bjADVZ6ctKO.BRdXskOw7MWldaOTrEv2.brgJ1IrFfBM3R1sQxhOY1TMR4D5KAW8cP8B8R4Vs PuKcjScbkRdyjokLrO5OgG.G.vk7MerD1QzeZGrNNWiGX9KT1FvIWJPAgZXr4AsnZHF_.XeKtSb_ 3sE75DiNVf3Fa2E8AJie.2pK3.Pq8PBb2tlyJaScyKuXYP594kZNS2i4ng6._08ZVe0MxAZekCEK bTnvA4n7T05_2ewcgrH2pA4.hw3aQqgiB0ShiAHEHVfDfdHp1jfS.sZpP.2V3VnQRf5T2gHMSLJt VJN5HISxueMJ7z3qK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 May 2021 20:12:26 +0000 Received: by kubenode569.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f1bfd44ac7e09a60b4546e237124c58f; Sat, 22 May 2021 20:12:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: http://lists.freebsd.org/arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: RPi 4 build time In-Reply-To: Date: Sat, 22 May 2021 13:12:23 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0299DFBF-5497-4A06-978D-13E4FBD8B5F0@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FnZQN6rLhz3sr0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard On 2021-May-22, at 09:01, tech-lists wrote: > On Fri, May 21, 2021 at 03:51:35PM -0700, Mark Millard via freebsd-arm = wrote: >=20 >> So, if I read this right, you are reporting 4.5 hrs >> for a "hot ccache" result, which I had mentioned as >> one of the things leading to large variations in >> reported build times. >=20 > Hi, >=20 > not sure what you mean by "hot cache" The first time ccache is used it has no prior results to use to avoid compiles/links: an empty cache (a form of "cold" cache). Another form of "cold" cache could result from changing compiler options that would change the code generated for (nearly) every file produced so that the cache becomes ineffective. "hot" refers to having a significant amount of "effective/used cache content" that makes a notable difference in the build times. I'm not that impressed with the terminology but it is was I've seen used the most frequently for ccache. So I used it. > - I always use devel/ccache-static > as have tended to build from source throughout my time of using = freebsd. > It provides tremendous speedups and generally i'll disable it only if = a > problem arises and am debugging it, or crossing a version boundary = like > from stable to current. What I'm saying is I don't know when ccache = was > last used for building anything. I'm confused how you can know it "provides tremendous speedups" while simultaneously not knowing "when ccache was last used for building anything". It sounds like you think the 4.5 hr build might have not have been from having a notable speed up from ccache? Remember that when comparing to my "from scratch" build times: in my build everything was compiled and linked, no prior build materials around to be reused. So I'm reporting a context where I know how to interpret the result and I'm presenting enough history to establish a repeatable context. > 1. rpi4 here is clocked to 2.0GHz > 2. ccache is in use and /var/cache/ccache has *not* been previously = cleared > (i'll clear it for next test) >=20 > 3. make cleanworld cleandir clean has been run on /usr/src > 4. sources are at 246839 >=20 > 5. this rpi4 has the following properties for its disk: > [i] root-on-zfs > [ii] boot-to-usb3 > [iii] 4k sectorsize forced > [iv] encrypted swapspace > [v] entire filesystem encryption FYI: My build-experiment boot media are never encrypted for the file system or swap/paging space. Another thing I'd not thought to comment on. As I've reported, my UFS based and ZFS based experiments get only minor variations in build times (variations of minutes for from- scratch builds that take hours). > /etc/src.conf is > https://cloud.zyxst.net/~john/FreeBSD/rpi4-main/src.conf >=20 > make -j10 cleanworld started on Sat May 22 15:41:58 BST 2021 > make -j10 cleanworld completed on Sat May 22 15:43:23 BST 2021 >=20 > make -j10 cleandir started on Sat May 22 15:43:23 BST 2021 > make -j10 cleandir completed on Sat May 22 15:43:50 BST 2021 >=20 > make -j10 clean started on Sat May 22 15:43:50 BST 2021 > make -j10 clean completed on Sat May 22 15:44:11 BST 2021 >=20 > make -j6 buildworld started on Sat May 22 15:44:11 BST 2021 > make -j6 buildworld completed on Sat May 22 16:20:48 BST 2021 So between 36 min and 37 min to rebuild the same version with the same build options and compiler/link command lines (near[?] maximal effective-ccache content that leads to near[?] maximal avoidance of rebuild activity). Cool. For META_MODE builds, seeing how long it takes to go through and discover that little or nothing needs to be rebuild would be the build times for 2nd build from doing back-to-back builds (not even an install to the live system between). The META_MODE use would then prevent most rebuild activity. I've not done such a timing in a long time and it does not approximate any normal build time for my typical rebuild patterns. So I do not normally time that. I'm not claiming META_MODE is similarly effective to ccache. In fact, I know of issues where META_MODE rebuilds files that ccache would avoid rebuilding the same file: for example, doing an install of a build to the live system between the rebuilds has side effects that lead META_MODE to rebuild far more things. > make -j6 buildkernel started on Sat May 22 16:20:48 BST 2021 > make -j6 buildkernel completed on Sat May 22 16:49:18 BST 2021 So between 28 min and 29 min to rebuild the same version with the same build options and compiler/link command lines (near[?] maximal effective-ccache content). Total between 64 min and 66 min overall for buildworld buildkernel for the near[?] maximal effective-ccache content and needing all the files. Good to know. Thanks. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)