From nobody Thu Jan 27 04:55:43 2022 X-Original-To: freebsd-ports@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 808BA196CBFB for ; Thu, 27 Jan 2022 04:55:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4JkpFT26t0z4QlB for ; Thu, 27 Jan 2022 04:55:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643259349; bh=AqfB2OGwUKURH1pOc5UjzIuWrtPDc20ZgvpDsgSHzUI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RDt1JC/U6+ypzLvvcxKOvf6gtnExzO0w9rp6ODAyKQpon3UD8mryndplzBMnK7zPDJ3jndQh14gqvROCmlLGtSPvoa3nfrT7Evn2SGbLeNov0xGf/itrAccYHOB8U9FS8OEpF9ghjfQe57TW4thV22rUvXeNzwnlXGuc/Ty0nB2v/O/MHUU8nIIvH/9am/Gvcm5ZcnTvk8mLsFWBa5wYfdE7AwpfPKIFCRKg3J1VNbcaW5Q7x+mPwEWtZEfXMFw1syPGCCK2vGxhAAj/B9L4VY/vMvsriE8qGuXZITQN7CPD5QEFg5FcRx3I7oq/WAwJYMjUai0qUABdut+K6plSLQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643259349; bh=hrPyRLxF5s6VbIC4jrj+DklBUvfwS9UIuQnF0zKRC/i=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rXtqymVP5G2C/EAVcsVgMFfRQVfH3Zx5chTzG+mCYZf2tuOeXCvmFfv+6ufEwsTdrF63zhVBzev0TEh+t1zuYBpyXDDSxeV9cABYbDcRh2TfLcyYqX3k6E0zqE/yGjzG7Ur7ZLoK/x5vZiakV2TFXNYyOrPiNgPqE+QCq3LKlSP3FnrWPagNGWzdnBC3pQGUU2ijluCv5hA/ouovgd+udFwVRDqhdFD775hXj7vMmmS8bsG8jV9Oel6JeHQL1I72ddoqAuu8r1/2LkwQ9fI0Vc3h8//RMsLQwtE2Nw6R3N9bYdXTg5XujQHcsd5xNYC4GDNz9/nQBcAtfKmNTZ3Jsg== X-YMail-OSG: OxK0.g0VM1nLwuioFS18by3t1O8zKU1pSDrQDbuxmHoYmOw4l04Rf0uO_YWAebl d1gze4x0MIQx1qhVUT1N.9tBW9dzp8AvfiUzlZstj.S4QJYhRVPTLEKtQYw5pPb2nRD7xyiu6C8M NVAkF19I5yq8LuxamQqw_D9egQnPUg44X8dCCRNdSWjKzEv.9pfCkqhs0rBMC7l8OFqfjH_iS_xM .vDeemcsOu0zKtdj9uZYtZiks1njURVzvgBQj0vPc3lehrxdwtccxOtrAHG8JhScT9Ig_Y6z5JAY Cjj6SDnHx7zEt5cFmNQLffdJ3yIalt16HYYeNT52pFUzAcNuP7psirX3I8YHE71GH5icfQuBgfZU 2BRBfSNNaMSjsBxopjkBk6yYaQJXzgr1c0.x0HuMnmxg2BBgINBq2RE_d7r.Pc9d6cIdSRnWBFXW eQgd1I5izitWiE9ltbkbDDpCX8Th8fMczFMvXeHT2dEHHJ.NfN77W8DsPeWuezQ65fH216EC4AeK veBrDSIvERxxxWcosdrRGsxHBCMRtpHyR8ITASOyEzvs2scwGmDCB8Q24nWWQZZaIlEPMuZN9ogx jJ6.IO7AcvLrOucG7fgV4PspGhUjPrlartRIgnwbN63wXg5GmgkbpRTxXZyfSzofkTABIGWyztbK YgGCqLyL6WJFULKJdC0.PMCVX9tTTs8iMgTXSB.UT_ee_X5RQfhNsxwnCOJ64JYCUGVBe1ebE_M4 QGdyxZ5.2Hi9WlMwTorkzwD5VjSdosxFuYvR47NZiE.b3XQSrt1g9WsTQTXt_IJtcXhWCBsblp7U 8yW0X.PzuGmo_pejHQhuv_jlJMY.qnJ.melsFuyWidk9EhBWqgZX19S8KyKMvMzvl4.6jR8ze3yM gq7gGzr.icfU88plUJaKLG_Q_zdOI0tOcODf7kDfSk0ZYsFEka16JtOP7durCJig7G8cyqtk3Za2 T8PHxKJYuno82WukQDXYNf5BLJZouMBkl0l1v0fNF.UWF2gLMwFl34M6J7hsxHGhmm4Xa5KX0C_p UeLU7ysxhWjjGJB3VIOF3GDaET.Ll1Y1k9pRRaC_GbiPPIy8ZdCX2eNMlt2EUdkwOPQNT8xu0Mj_ VZy9ZaydOkyQ07H3hLWjRty9O7FIkKIEKdH4w_6TJLhlf1ogXOIJOIc0G91Izis0fsVqFK1pSCHW pOwUXHr88.f5lAqO4uScd8XNIAB8BjLTxeAGLtl22QJEhj_MViPdhfrKolbOdRYua5v3JmThZ14b sT1xj8ytpEKAaFYJqGFcslyfmdm8H3gD64Y9uXeZiLvzIXBzxdQNR6RQlL4Qca.MaBa8NIgOMvKO 9rVZYThiXtWy7jVKUlsUWx1SixQjaDs_ldrLvo45XXiogmo51ysW.qCxZGb7lVi1iSxUD56ZtCRC 2wOQlB7Sxlk5WoE_RFxSP6y7kt55UaKZImKBGIeoPuy5Ptrnp.EUd0CxDU0E.uJKjT44EKjzp1Cg UP6mweDi8O.C6Sk3AIJ_c0AoL.qUW9vzaUGZtFZA71xuh8yKMCIaydE7iPPTdKAf_GK9AO8V5RU1 cLzCzT_32gW3Lsckpv587mSCfwzB67_pKND6F1GGnS0hq2yOti5mv.URaT9C.2wBkCQKaI1McTLj R0rBIiu_L6.k9EYevznBmcl8rTj7NLBOhFd4giqrac3gXZ9FdpJSxDujUwvIqyuO.sXSIWGGRzkE hmrX.2s87751hftPHtw0ORFI6eoFbNOZb1CDSgxKB__JFgV98a_y99gq3AIOpuBc2YRZ6cWGmKdq _Y2iFsA4O6sQ2l99Id9Kp6gashyC3lVtL5.k51YdrdxgbZ6wqQuze_BCGAy3Loah1NFzTkdra.97 UScXlNQ9_QseGaDvNwLftbdUzcAouTyxwRo6hzw3P07REqqwOD29GwC3ssKUbcZF4wvtc2SLBgtI r8VxINsbgHQu4V9kU_A3QqHqWJdQ3gHXjLRs_AyOYxNCFHN5w8TANpb5AfqUX4dTAcW.fDbr91IH IwraM6YOFuiV6Ke_FQx6eSNlTEOGG.ZZmnshhxvjmHqyvANo3nD9stPrpUgamxxT_rBsQfYI4m6s GBCsTmtrXh7Ooyiyj1jkR2LvRFKdVj35qo.EScWVioJdmD0qTI8AbCEHVbHYgtErKcKk7dkiSPJz L2e2di6end5XIfwQL6Tb_cLviq9wEaA9OPXS3618uSxCRUFI8n61qB9AhZuRcxRxpkrMLGh0JwCe SvAGw5x5bB4NjbVOog_Ok1VvwRqKb3IwEBQ0ExuabBySZzjeQ.JuuA39OoqCMXFVB3KwtPEaq996 7kQQNzHOL8RarKbmHGfltwg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 04:55:49 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 57dc230c93711c429b3eacaf1fa7a3d4; Thu, 27 Jan 2022 04:55:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: poudriere and MAX_EXECUTION_TIME_PACKAGE vs. NOHANG_TIME From: Mark Millard In-Reply-To: Date: Wed, 26 Jan 2022 20:55:43 -0800 Cc: FreeBSD Toolchain , freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <701E3CA0-8436-4459-AEB2-E8EFEE77DCAB@yahoo.com> To: Bryan Drewery , "bapt@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JkpFT26t0z4QlB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="RDt1JC/U"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.60)[0.599]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-ports]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-24, at 23:14, Mark Millard wrote: > [Just a resend with a corrected email address.] > > On 2022-Jan-24, at 22:05, Mark Millard wrote: > > I've been experimenting with WITH_DEBUG= port builds via > poudriere-devel --including some testing of bulk -a . > > For something like devel/llvm13 the .pkg file generated is > huge (multi-GiBytes) and takes more time to produce than > the rest of the llvm13 build did. This is with that being > the only active builder (no otherwise significant activity > on the ThreadRipper 1950X in use for the experiments). > > If other builders or other activity leads to load averages > noticeably above the hardware thread count (32 in the > context), that adds to how long teh .pkg file generation > takes. > > What I noticed was that setting MAX_EXECUTION_TIME_PACKAGE > effectively did no good for the load average case if > the NOHANG_TIME was shorter: it stops for the NOHANG_TIME > during the .pkg generation instead. > > In part this is the lack of having any output (progress > messaging?) while the .pkg file is being generated, although > may be one could argue that the package phase possibly > should not have NOHANG_TIME applied at all. > > I'm only noting the relationship and need to understand > it when setting the figures --and the need for large > figures if WITH_DEBUG= is to be in use for various ports. > > I've not checked if there is any other phases/activities > that might have similar issues possible. I just actually > ran into having devel/llvm* builders stop for NOHANG_TIME . My context for this ended up being somewhat messier: 2 ports really did hang up and, having set the NOHANG_TIME to the very large values for devel/llvm*'s (and the like), the hung up builders would take a very long time to fail, despite hanging up early. After the increase of NOHANG_TIME, I was not using very many builders for other reasons (disk space vs. devel/llvm* disk use during builds). Blocking the builders was not a good thing. I hope that, at some point, having a smaller NOHANG_TIME and a larger MAX_EXECUTION_TIME_PACKAGE will allow package to run based on the MAX_EXECUTION_TIME_PACKAGE value, not the NOHANG_TIME value. I'm not picky between: A) pkg outputting to the log once and a while vs. B) NOHANG_TIME just not applying to the pkg run. FYI: I worked around the hung builders by killing processes that were supposed to be doing the build activity. This avoided stopping long-running builds that were making progress and lead to freeing the builders for other work --instead of waiting for NOHANG_TIME. === Mark Millard marklmi at yahoo.com