From nobody Thu Feb 29 06:59:14 2024 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 4Tlhsx6P59z5CKx6 for ; Thu, 29 Feb 2024 06:59:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 4Tlhsw5bb4z4fpl for ; Thu, 29 Feb 2024 06:59:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fkMqbANe; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709189971; bh=OOjeYidHC1EJ6dNheQMvyQn1oQveobZg7fd8s/KbmRo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=fkMqbANeGuSGwOo4KE8yan77aw4FHsU7iu2EfxmrROJX6kNBz+UPYRUUq8wHOh9wVmsSpojvGkVOVxOUzGV0iPEWiQW+mRmM8mtJVuuhRtha1j02TjXSPCBD5e6blvYBOE4uwM/8BPaLmSEx90DnSRTr3Pxq7bwjo3p92HFKmfHclACdFI+Tgq8EmJbE6y2EOM/kFZd6sHJ0EwF8Cv9IP2KrC7we/RwH6EiL+KMSuPrpBj4WdhBK34dpILCHKHubLoQZ9lNOlZhun+uRPpz2H/ircutfn0ze05lPC46w5w2ryCM8qhtLKBI8BK2nUKsFsyUYOtcdg9OawP5Myt6+Zw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709189971; bh=K7q2RxLiBuxDHdnCdbLfUojRC6NqGQxpGj7vSHM62F0=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JOWjYHSXKDTJ8lrIvyUWnepTJ1AQ9kVmRgo53uglz+Ye34CtXwKWnQgEbIuJJ7209aX99x0L3h1RVMTLoRZCUjwhG31v0BQ/9rp4WT/HcSng8f0DOphnebLdIpQOhVEp5Rap3phA+5Ub8dkhddkA7gKYCSYrgONRtwLPtsOsKAvlPk47LjCrf3ao2iLjZQP/zilc7IcRKQkaGWOhB12fsXnufi9EvLi3Fd7EwnCgT8dEP6ttb+89A6gK1YCih3aTduTU5rrFuihh/6GkGikzdL8981x2oKxdWtYaEeeENsZiUjzgH/0leMnARNvGpBMi/+/DjV4XH0dxNLhvhc5EAg== X-YMail-OSG: 8mePbY0VM1kOWVPnF75GTbORsdYZH.HYoabSDi85zVCamypaWpJ7ib1YkmLQXkt 35wB.khRM5T7hWGOAkH4a5c6k.f3ruEU8zvJyHEjlB2mT.IYe2Z7KS.Ku9f6fZ5fJh7DbXaN.Uwm lbqQr.MKza1YpT_gynzNMXlKajOJymqEelhaVUZ71tjyep40tY091Ef0qGA0AiGkHb1mMGlCANEF 2hMuW2C4jyJCO5jM3v.ugf289CycZycrJAWx9VD9CCHZM0TZTAjyZqSZsMTa7wC9dVazNVJ63eO3 HvNL76jha.vm6x7qBlDgz9hHTcDofHXFOu3hOhAgORKhV5TieSkaP_7daWxeItCuXwzah0x6si2j kO94OV27aHy0an3Od9IlLSxuOxh_FmMnI_lp60owm.F190lZTTGRSK5RBHITHe2gMKPtW7_o.DiQ mbGJmZHymPKvHV34eMHwliEFtw5d7ri2XxxPYfGu5s42XBFhYSdaEwY0HjeMvN362XcaO9kkykW3 rmaem0M572kY2wV_KQ.D.3DCfZTq5Nai.p77H8angJLyn7.K6ywKBxd2xzZyty9OlJI39hMDZGfH Q6szZwtvb76gvy4zRLjX.72W5zdit2_yg9gO7jZlKLqN3goZ2O9sjU3sHH4XMRVJekN87Pv8ub4Z I0x69mQKEMP.jsbCo5mR.AaCBtarhOEbpNCm0Sr83lckjcCNS2XP8X6yu7vIpgIH5CJ5SBBjT5c2 BVq93ltoUqhfyo7pnaJFEHaUbm8Ok.YFvGAKByb0BegZO5UGW0F1aCXe1IDsYnx8SskLGCsNnqpF _gym0wSC0_N42MjqWRBILOi.GwFpQj7l.DydAE2ZGX211ewazkJG.ElPScgJtP0xODbTsEUwJIHY F15iprE2s9AMk31b.edftrAxAY9M0SQUR19_UTuA0RXhm4wiTE35ssDyGJHl8hNRHJjxPRAIpOAq A5_V5LK0tjN4Le9XV5wDcsYF7E6HL5ETiECFaYUBRV_tiLCZelTDXhj_elA1dvn6tr7MYrtpKV_u PY4YjHna5JxqliUwRmhQKNpth_8XlHxsDgkicsJxI8P18hrz8m55Kw4EPaP8VLp5AyBjYSXNMlPi nioPiegjX.h_zXLy8jG.Yllu9BCbpFmrf80Dl70kvVqPJ96aUq6E33jnXx5Pwk653qPYaldsHqlE KkqddbAglVqyy34ADxFxwc9carizz9QP7mcw28E5z2sVXHIs6_Bs9CRXAE4KyKG46nnrjdp92yv6 ZmJYhvaWL5WXa3XvTg1IHvqfg4ghdrpcHtV2HG46MGfoN1Esy0tIoKVd9mmHojXSn.fnLPvFt1XH yDboFEPR20NAYqiAYeNNCmyhBfcUQBzfJ9YCSaT0_vyrwxM7oCG1gJnw28up1jDy2SNIRDgmFl3g Hh0eGt1_jOTCnYWaz2BDVu8juR7HKQ6DwcFH5CREVG7Y4RrQrnWQKzeU7YvEl0j11xnRSxiWYu.5 7Ggef9dyR9Mu.UCRrjQF8sMBX6xbI2kzygBcjmQjVaXebuL2HXSb7atyeOqUqaRhxRV6yADYf0y. bjFc.5JF2dL0QqI0.tE3zBGRkLAQtl8PHbxSzy78ac.A.fw0LGFdX3jN7DNUWJBKNqqj0tnKrjm9 GQdgxTyOsnlL2Nns9.gomUWxO__RaMRAousevNMIsNVDY_WymTZmGcPCEc0vEJFP7CwDxO1Kgz0M oO_qY9NUfaVOTz9dRpFPM2NUwPC9ojoiuVjBP6SRANuuKAERZAx6dDdVOHX2swnFKVUxMPFtcv60 jGjJBTUVqwpeWPzFiHYqJel5t9otGkJvjlSn780VZJpUJevtO_x0kWzrOpQ7ne1XWReehbWtsv1g q_GxsG7PeI0eC8dnDDMhCCWR3pU_Ttku5HIjgXUlucNDmcz14Uy7xSE6xHp7y5Db8pKSjN5QerFD vTv2upInlJqJDgffTERuxa6Y8IhjXz6GgPFePc7qKa9R5nLPt.eTHmjikvMLEeh9xf4zGU9d.YOM BLpPHxMaaylFrknETJzcPv1sEFaGgD5llwvtTK1Nseb9YEWS02wWps8x5f7mmi5Dj798hDhs9TDL 6n2vq7WQO_g0YJKSR5n1Fwyy1hzqqny7qglInaNK3Da11tyaKMIG2a3cQ9JejiLdoMEvY6mtuw8T EwiehCkLRJU1.Wa.safLT6.udEITSo6n.xrcQ_Ed_tmD7pdBIlAr439WcFVPlxy8GKuey8yPQNRs yU.CgCo9WV1am0Z3I.bq3iuZmmNmPjmbsB1bjLimy1_QUkFCwvYg3U0B5.5ONxKG74tEuL971iQ- - X-Sonic-MF: X-Sonic-ID: 455662a7-b19e-4d98-af3c-62cd0bb58819 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Feb 2024 06:59:31 +0000 Received: by hermes--production-gq1-5c57879fdf-tnlsv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e7300e207d73b16100e2b401cf9dcfd0; Thu, 29 Feb 2024 06:59:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3774.400.31\)) Subject: Re: How to investigate an unexpected port build time-taken relationship in an aarch64 context? Date: Wed, 28 Feb 2024 22:59:14 -0800 References: <7D640D5A-7514-480E-8D5B-58003DB558E1@yahoo.com> To: freebsd-hackers , FreeBSD ARM List In-Reply-To: <7D640D5A-7514-480E-8D5B-58003DB558E1@yahoo.com> Message-Id: <900B51D1-2005-4281-BFBD-96B49B147A13@yahoo.com> X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.71 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.71)[-0.709]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from] X-Rspamd-Queue-Id: 4Tlhsw5bb4z4fpl On Feb 28, 2024, at 18:46, Mark Millard wrote: > Example HW Context: Windows Development Kit 2023 > 8 cores: 4 cortex-A78C's and 4 cortex-X1C's > Headless: serial console and ssh access, no x11 or the like installed. > UFS use. >=20 > Note: cortex-A76's are missing 3 or so instruction set > features compared to A78C/X1C parts. Use of > -mcpu=3Dcortex-a76 generated code is compatibile (and would allow > the code to run on a cortex-a76 system, such as an RPi5 once > supported). >=20 > I've been doing poudriere-devel bulk timing experiments based on: >=20 > A) PkgBase based system software (kernel and world) and > general use of default code generation for ports and > such. >=20 > B) A personal -mcpu=3Dcortex-a76 based kernel, world, port builds > (into packages via poudriere-devel). >=20 > C) Also use of an armv7 poudriere jail based on armv7 PkgBase > and default armv7 code generation. This was used in both the > (A) and (B) contexts. These also show what I'm curious about. >=20 > Using the armv7 poudriere jail context for illustration: >=20 > For (B) used via the armv7 context: >=20 > [05:40:24] [03] [04:55:38] Finished lang/rust | rust-1.76.0: Success > . . . > [05:45:58] [01] [05:01:12] Finished devel/llvm18@default | = llvm18-18.1.0.r3: Success > [05:46:00] [01] [00:00:00] Building devel/boost-libs | = boost-libs-1.84.0 > [06:59:23] [01] [01:13:23] Finished devel/boost-libs | = boost-libs-1.84.0: Success >=20 > For (A) used via the armv7 poudriere jail context: >=20 > [06:33:21] [01] [05:40:48] Finished lang/rust | rust-1.76.0: Success > . . . > [06:40:05] [05] [05:48:09] Finished devel/llvm18@default | = llvm18-18.1.0.r3: Success > [06:40:07] [01] [00:00:00] Building devel/boost-libs | = boost-libs-1.84.0 > [06:57:48] [01] [00:17:41] Finished devel/boost-libs | = boost-libs-1.84.0: Success >=20 > The curiosity is about the 01:13:23 vs. 00:17:41 boost-libs: The > ratio is large and in the opposite direction to most time trends. >=20 > Notes: Almost all the time llvm18 and rust were building, both were > building but little else did and the load average was 16+ from the > llvm18/rust build activity. When boost-libs was building it was the > only thing building and it looked to be single threaded when I > was watching. I should have been explicit that the 01:13:23 was mostly "stage" phase (not "build" phase) and I was referring to the "stage" phase as far as single threaded is concerned. > (A) and (B) without use of the armv7 context got similar results > when I first noticed this but I'm going back and recording times > for some variations. I do not have those to report other > pairs of results yet. >=20 > (In the armv7 poudriere jail context reported:) > (B) takes less time for llvm18 and rust than (A) does. > (A) takes vastly less time for boost-libs than (B) does, > approximately a factor of 4 for the time-ratio. >=20 > I'd be curious to get a clue what contributes to the boost-libs > time ratio being so extreme once I have figures for other > combinations of poudriere jail content vs. the system's content. Turns out that for the aarch64 jail (PkgBase system and default code generation), stage started about 10 min into the boost-libs activity. Package started somewhat under 5 minutes later. End result: [05:55:56] [03] [05:33:12] Finished lang/rust | rust-1.76.0: Success . . . [06:04:37] [01] [05:41:53] Finished devel/llvm18@default | = llvm18-18.1.0.r3: Success [06:04:39] [01] [00:00:00] Building devel/boost-libs | boost-libs-1.84.0 [06:20:50] [01] [00:16:11] Finished devel/boost-libs | = boost-libs-1.84.0: Success So, very similar to the armv7 jail result for a PkgBase system context (aarch64 boot and aarch64/armv7 PkgBase jail, default code generation). It appears that the boost-libs "stage" phase is the context for my question. For the jail code generation being based on -mcpu=3Dcortex-a76 code generation but the boot having been PkgBase based: Stage started about 11.5 min into the boost-libs activity. Package started around 48 minutes later. End result (showing only boost-libs): [01:07:01] [01] [01:06:31] Finished devel/boost-libs | = boost-libs-1.84.0: Success I'll note that bjam stays around 100% CPU in top during this much longer "stage" phase. Definitely less than the 01:13:23 time. MWCHAN "-", STAT RJ, PRI 135 when I looked. For the jail code generation and boot context both being based on -mcpu=3Dcortex-a76 code generation: [05:16:38] [01] [00:49:22] Finished devel/boost-libs | = boost-libs-1.83.0_1: Success Also definitely less than the 01:13:23 time. (I'm showing here an earlier test when it was boost-libs v1.83.) A ZFS context (instead of UFS context) showed: [04:37:47] [03] [04:03:16] Finished lang/rust | rust-1.76.0: Success . . . [04:43:47] [01] [04:09:16] Finished devel/llvm18@default | = llvm18-18.1.0.r3: Success [04:43:48] [01] [00:00:00] Building devel/boost-libs | boost-libs-1.84.0 [05:41:46] [01] [00:57:58] Finished devel/boost-libs | = boost-libs-1.84.0: Success =3D=3D=3D Mark Millard marklmi at yahoo.com