From nobody Tue May 23 22:31:44 2023 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 4QQpw31mtYz4T875 for ; Tue, 23 May 2023 22:32:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4QQpw25t1qz4634 for ; Tue, 23 May 2023 22:32:02 +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=1684881121; bh=O3o7NM9EH9cD3JcMpLGcmE18FBleeesF2ZaHIm4ZOlU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AfrhueLp3yFuSTKkeWo/NDpoCFAaIs8eWW4CowxtEe0RoweKLaCa/MRBIT8vaiTLpsN10AGI2OhwsXdfmMqkr7MpgOh8voNTJAjYISvZBV6N2klaNv/HSD/lELI/izjqPRqKjJRm2yImvc7esD5J2LcQjZP1vQPMRZy+OmGhMgKq5IbvD0asuxJGpT6eKtHujUTEaD7Z3xjNkdLGvAEIjaXB/b0rd/peKgy7vJ+K5Cc4YCrwrskxAx0K5WIAOqUese7ItuIqMFXpeE43OEB1aUipP82kRj8x5h3DMmuLCMUsIlD9l7IPO2/jJVMm0M4zcyT6oiv0bEnA1MiEDEb3gA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684881121; bh=XufvXpMLm16KdKz2Gsu/cNaVAQr2NdTSzksipOd5bxi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D0yq4bczZg0+DmFkjPC3zfzP5jCA/IiNKVV29/RImEdR0HTbk1rtgbquHbfM/MeOC4Gi+qtZTUWlhlqUiYKFJAXR+t8+fo2E4SldO7poIx9WntU62yI2BDa74VVhlrrTR45eA1gMVXAWzo5tFvyWe8MeFc7GwkY+p4ojIMi4eFsB6Dcj1cTHgFKIs3/NkLzeFrc3aMSqL8rI4DOkqdXInvwBdE1BqjP0zVh7UxBUQ/f1qjn3vb4m5/zxcZ4HI0ENiFv2hrhfcxasq5zjcbERVS1H3N5baSUO+wszgs+PqcD9lgdrtGH+GgJs8yswtTeamiCwu3UW90ZmEJUoyxwTYA== X-YMail-OSG: djlyEKcVM1nV2mu1s5P8GAc478Udk3WAnZlDqwr0U1dCr_DUdFsUC3VuFDbiVSW ZufhoobxUpk0XwKFx_SVM12cNm4mbm3d.DVt6SN7w86gBYaedSu32Qid_EKQSsKTWsLcwQpcWJCZ Mu1KxyEr5v_D0oBwLlDW3njdXJPqEsnZ.OMvStOqk_1EftJ9Vt9e9FEuitK7LKefZMaf7nUJ1GFD ghCxJUJXsjpemAZ_95X0gx6k9ZgH0sYRqNDg9IA8kq1SQsJudWMmeLwiN6GdYJqh2FaDn2AlLcvS 1_Ue2bcXazHClgFj9LOmAcaWQ1ReWdubEvrlcBgBmRkvIy_M06cD7BShUKXB6ahEXR.sWDxQBzJf BlLbtipcuWOgNetyH2V8FRpK97INKS6g7DJeckVkLwfM0vEE_3_3murNXxJmHqvWCX.JndidjpXJ gccKk0lcamLzwXgwndtxbydZ52odXJ0yTC..BX9_nHFQNuQ9z5HkdZEKZLnbfw5JNfxspiTQ3ecl L84QXSEtjxOSTAEbUceJKpXFw5gNeJiCoQJ6SF.cYeQAbfVpGiorRAUNTa7Zw27Mc4uzXyjNiSTY Qqrho4i2BHHaLuDzQJ8.9phwmw.0VkRAtdxPiRG16tXeg8a6i_Jmp8S630byjW6lmNqoq1Ny2E2H LJWHTXG_IgcXb2zKUAlAw86AlBK4IjjQbi6FNEBLWCoVGPmg2qWQfl5mTNIVJ2BC3CQqFQftw8Ut y_nR3KrE6q7fz3rpNJ3oTqAbvwf14jv5fO8az.o36_WGEV8dzA01Qqra.XaRlCfOtGRhK6bzD_jw n79IBW.JAskcjJJyJcP1NVA2X4i8cf2D7n7yS.7vnXT62IA5Bg9uXWSVyf4aVexppEGTfpFMNsbw 2Z6Wrr9UfdGAXjZJCJxx.KrqQfrUCz9gqrxnfrhdO7QtfuQ2NQ2nrjsmI_nYRjBkCT.emsb2xXd8 uJeubhUQ.Mfp8NPMn_29NtsHcfRouyWrvegfil5vkfEiu8PQXH0wdisn67PKn1MbtSe5RPHN6PWa QX8MHVS3fyg3Phq3AojtGkVjyYeKA8cNyojfQHGDma.zpZog9HCA0klGVXsR_GzD14MqmoSwX9AX ARiWF8WhesObRyDBnQPMzHB32rPzw6l95U2EDnyDysWPbqK.36KKBJNkB3ODrKprwTE7YvZfGg2X hRiHeLOaDIw8F6O0UWLiOPe.YOik.w41X8W2t7zlZQIuVR7BXs8h4YDWQ5y0tTSpOuSEos3OgeDj uycKzZ8r59TJd8Hmsh7KrPH1SamoGJPlQbDCtF6mx2CI2NNLUra..eAEAKjSCiWGVWW0QW8lC_Bc phTEh_tiCl7yNHs8I54uQccUU1BFAYV_1m95E_HeaJepkYqVu71aNvJ28QAPgHnERwOV40oOv6YG Zdnv9Pqd9l5vrH4BRFrjCH8C5PXHu4yGQtYeQ8rq2X_4S01YzFBi.V9eUhuPmiq4X4a9ZUy11maE iI5ezKXOnPN0MbAOvUU4F6CeQQetCmhNwHhQKtkMseDLw6rjjdGDjKLkOM65n7zS19s6A_xLr3h5 xpYy6GV2r1kMnLwVtqKL2ZWj1aI6_eZ5BBi27ZJX_ZMGKbnZ6H9IgAs7_LTaFqRkCdsnVOz55uts jFBJIMOCy.KWclBnOqNBS8HJ24HwehDi_1AhJSk0iU3bjnH5fy.M.LjY37GKoblOtnlbva6wD9oB wNDg0eYPRZg4g0b9qPL6AL3jDrkrEWCQq0ReMRUV.1uEEt0vXOmWHCJS3nXIUvWAj3.IFTfm.kMB Nf2dGkIqu04T2jkK831SXOx4Xo8Nwz8ZDCzHrmIgCahKwcPszJonDxYbvlk1Birs9_nzhilZQEjx yr9KahT1OSrYfeATf1wzQ4MmR4P1R0zi89dsgTw49AmYrIjacwgWKcmm4u5warrTFylQ7dYGbnqi aYed1wIvy7y.ZQnVSnTxBcImFlqN0nEI0kxuklXa.snPU7nUvGIFmaJ2olBIsSX7JFPVEo5mF2zD 3LLr9MTbfsYv7beZLroO5t9Hv.by.bLFKZKXcGtpTOXRKWclVplF1SdTmpxw0rc6a3Z_F5KW7WHg X6IXbxj.lFB9gmruy9HC.m86pH_4CJzrN2m4ePjc7eYjl4FUuXgk5oLaRB8F9N3Pot_kKZ0ihY7n Ldfqs3ykQOnW0zn5ECD3Kq55oxl.cfSzVWHaFYVjCqZMZKiw6yNPfbTDzBHVH.RxtIE1HSdu36HH Zf1SPCyMrtbOi.vm8MWXPAEg0TzZu5Vw2lYdbzuK0mdl.7yNl95264yPNGxG0uysL5.p4m5pgFWR g6ig- X-Sonic-MF: X-Sonic-ID: ef8028ac-e497-4dc8-9fce-78e6fde4cb53 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 May 2023 22:32:01 +0000 Received: by hermes--production-bf1-54475bbfff-gh86g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 64e34d6e22758fb9c5635905b4d3ff17; Tue, 23 May 2023 22:31:57 +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 16.0 \(3731.400.51.1.1\)) Subject: Re: Improving www/chromium build time on arm64 From: Mark Millard In-Reply-To: Date: Tue, 23 May 2023 15:31:44 -0700 Cc: FreeBSD Mailing List , Nuno Teixeira Content-Transfer-Encoding: quoted-printable Message-Id: References: <1623315797.5.1684837400228@mailrelay> <44E30F5A-3DBF-444A-8633-7ABFB7F41888@yahoo.com> To: Tatsuki Makino X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QQpw25t1qz4634 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On May 23, 2023, at 14:55, Tatsuki Makino = wrote: > Now that there seems to be people who are building chromium and have = very fast machines, I'll hang around :) >=20 > I am building chromium using a 4 threads cpu and limiting = MAKE_JOBS_NUMBER to 3. > However, there seem to be moments when the load average rises to about = 7, even though nothing else is done and the conditions are calm. > It seems that node is being used by the chromium build at that moment, = which by default uses 4 threads per process. > The basis for this 4 is a variable called v8_thread_pool_size in = ${WRKSRC}/src/node_options.h of node, but it can be optionally changed. >=20 > Here's something I haven't tried yet, but I think the environment = variable NODE_OPTIONS=3D--v8-pool-size=3D1 would limit it to 1. > If the problem is that the CPU is overused, this may also be one of = the solutions. > Can someone please try to see if this makes it better or worse? :) Last I knew (2021-Aug-06), an example process fanout looked like (extracted from something like a "ps -auxdww" output, as I remember): . . . `-- /bin/sh ./buildscript.chromium `-- /usr/local/libexec/poudriere/sh -e = /usr/local/share/poudriere/bulk.sh -j main www/chromium |-- /usr/local/libexec/poudriere/sh -e = /usr/local/share/poudriere/bulk.sh -j main www/chromium |-- /usr/local/libexec/poudriere/sh -e = /usr/local/share/poudriere/bulk.sh -j main www/chromium `-- sh: poudriere[main-default][01]: build_pkg = (chromium-91.0.4472.114_1) (sh) |-- sh: poudriere[main-default][01]: build_pkg = (chromium-91.0.4472.114_1) (sh) | `-- /usr/bin/make -C /usr/ports/www/chromium build | `-- (sh) | `-- ninja -j1 -C out/Release chromedriver -v chrome | `-- python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle . . . | |-- python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle . . . | |-- python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle . . . | |-- python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle . . . | `-- python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle . . . `-- timestamp In other words, third_party/blink/renderer/bindings/scripts/generate_bindings.py was was in turn creating 4 more processes for even just one: ninja -j1 -C out/Release chromedriver -v chrome in that build attempt. The context had 4 cores (4 hardware threads overall). I expect that the generate_bindings.py did not attempt to manage its active-process usage to fit an overall total already possibly partially in use by ninja or other things. It likely just used the system "cpu" count, independent of other context. (I did not record other activities in the old note. There could be other fanout issues as well.) The note indicated that the example was from the time frame of peak swap space usage. I've no clue if such is still true. Nor do I remember any other useful details. At the time I was helping someone else examine what was going on with their build attempts. I was not building such myself. =3D=3D=3D Mark Millard marklmi at yahoo.com