From nobody Mon Sep 15 05:01:54 2025 X-Original-To: freebsd-current@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 4cQCZB5hYXz683hd for ; Mon, 15 Sep 2025 05:02:10 +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 4cQCZB1dVGz3JNb for ; Mon, 15 Sep 2025 05:02:10 +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=1757912527; bh=b9Je3MmxQIgL2evuCNuNYAIn7U0RapPFSdLcC7Aj2lM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TSNUBU6YzlxJBzL7o+xirteeZyA+GxIsA9k802lWCabQaia4thc8ww0522fSZrSnoa04UMw/9+40ugRhIjV02WEhQh+8o7rsMQwI63an54WMPIUzC2JPmBqLuGP5ktnm2pKQvrSA35RmukxqgoblOv/Z6Tfe4h4G5U+XISmzE8T+JMbyf+6yd8uegEIsC5+pd5LCVPsVyA27HVTYF14hoA9caV8T/LlXZ2dR/I46HjiBaEhv9hs/lLPRQXUSgbYiPGEfUn6fqM9PaWNu0kmOnqW8frTGO62zm7ZOMonNMNgx2/W61fP+/CXAl7+C7vmNqXjSOkkeG8ujl3+OYuIt+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757912527; bh=HihooGW5XJJMnaqyaKO4WRJgRziM0DxpIkatzCz4TO9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZyqjCDO0OzeYSeVZDldwrwVaCMH04mTuAMcy9q6TwJfj84ALNWAtjjY5bjjR7TGWz3ZQt19ZlFFnCExbsSWUJWwt8ZXVrjtKgCuvU7LggSG5AazYzBRPKWYkkWJf0UYTwFlDb4BVPhzX5Z6/6Q2co2HpwB09YfZUii5uiIxsQhUDuW2wMm05eomba+PNduJFuTXooCzarvUJTkKCJK8Zxljh9xYyh5JFA88gWsHYG/v0Sy+f1i0W0fEIVT5rCU0FGSZYeY/Dw0zuMO8m9bhKEPpWlzCzPo0862SGl+wJFouSby+pzE0dpEE8N3Mnp7Eo80vdOq1DAtTh3IlgSpT3PQ== X-YMail-OSG: HF7aKsAVM1k5bwpAa7r8zRFeOPc9ZbiRWuJKGIol3016ClOCt773iP0gljZ5yDL WutQE9K7CSTFyJ19AdurohkmJR_7mDNc6JMUAiJsaMmlp1K26_OpUhXqoqPbOsS1c8QH0shN.O.3 sFH8WJl8SkbIMhQelyuEaFUdflQ4EZI.eWmYVfZeIn_YGwqN32KLySHH0Z_XReKyZe59mc6rnvtz K99B.WZnb6Np9ltNuaFBzlHYOO3GJ2JmiJfODIXC5e83IoW2f7LEwJKi3wwYxQYd2rj96CtZZMzZ 2ab3CcsK0ySumhWDULDnUZaU9YvYW5I6_XgIbgfKhpwfFUillDcXpAYiHgjwtWpGBrwhhTwtGrBV 7XEWuz3LysCLWxUO867APRDRmfpKB1tDGnRiIPodhkjxBX37_QzEWeX6NdPUfIGGlU5lAzSTGSug 10T75WJmCB7ZqxtZ.dTKeme3MQXmmW_MWNMQ7MUOmRmjaftPw3jtq4K7nf_VQyhClFJRs_BM1LJP O13OXxQ0SS6TFNtVio1buBNRYDjlBfXehQr.Bd5YoRJJ5aHOJdgBBXhyR1J7lbHi4bbbTgHFjcQ4 TBR4qUgR5AuWE0Pbmpa5snfl8L0Qa9mRDE7V2Cl7o17tvp8SBiLEat5i9bhcr7VQ383w_2DUkU3r bzpCTOnE3ixPX8lWCeHJbFUbkGBBsgADaUyhWiuRtsGJXfo7d46JkaYqKFNyUiHlCKRIlFufKog1 h7KgHEQg8RCAFw1Mdt7F6ci2RTdRnThBHxSJKcp4ROweBkpB8VcSQss4ghxwbV3fAhbiuEpyKV7L I5NjdlU5d4R.GjGLYq2mKjiN5LhD3thiShtKydmwZjl3KcKy.IzLdnhfCYBWvjtoECclevqnuEvf oCMQx1p5MfJFrjf5sUJC2TkpjcrZ2oyZg4_MK.xs_8_LZloAYS.pCpAUIIkh4tkneog13_g5ZPAx 0ANUYFNGYH0yKbQZM7tmQmMam4eDjo6s9pEhnForTcN106KXl2E1KZ6uhl4YJ3OKTMoDmDwxawvf gOBosuFV1Qum87HDRmb_vgl1kg_N_3loQ.o1Le5.LBxjJEG9svRTHsgSUss.9LSqfGkIs.Omd5fb .92HFTfWk07Noxi5SFnSbdvaj4H23E2d9LzHrzZ47R0zsAzH3qOrGFAh2v.88ukytZ21iBDNA6xB wuX6jmX93gdvU3rukiJohP1cMTdF0lBXnqBfKbcV9tNGwyA.Z3zMsHRxH4fFMK7meN2J_kR4TOxy f3PuR4UFaFsYngaAeKOGNIdpOw8doa7d3ohYVxm2IUCYNPWFUwpMsza4kf6a9e9Sm1nZ0hYap1df we54rXmMv3t7RMdXG8eTmt92AT8E7ZNT4L_1qcq5Kv10pGFhjjoYVwFoeg2Tlu0ETDuNNpbvGsOY 00Gz8e_7Vcpq0T0zfIBW_hGFmJoyNBlUI_CoqIvIGjgNK2luWvApfCx_Wk7SY2xvLg1lZw.iOy7_ kMPa6u2FRLc9Tkc43ryUsJS.x1kjvdJwga9mvT9cuq8VhQRjJk5aSorratJ0yI36ZXzYfrHku8Ql JxMyon1dqYiphaorx.PzF9J3B08.WOsej9VI7zonVN3C6Xd0RHBvqtM2fUY7NrKtA0arnNeR1Uqh l6lQSAY0SobklTIpgBZXHZ_A3C9VWokdhafK_IYITKS1jeovfKnm35B_.IrxKVCWxV.AOG8kdw63 uB1V8Ltk467waZqAh1SykkoQ_qV0KHtv5Ym_WmLYuo6O5YXNYjPnuKUvL67t5LS3V9mUQ9uw1bn8 nM4DfPZRg31MFKI0EtBPZsYS8hJKOvPCHC9aP3v.08dE.anOW_xx0UGOjhRJzN7nYys7XerNALxu 41XIq5DA826jbnIW1NG9HmUK3n7rBhBXNzJjPvvAj_nojPhohzN06GKWpLnjvGyReWQpUmbqoPLr uza6Pq1AvIgv.x1bJNShk0Y3I3sI5B_zUMVTQoId_J0JYRo99WOelExT281rNHFIRunu08JbGfJG mRnE4Usi.neTbjOp67kXze9RXgPpf6u1YggnKF5TjBtsJB2GzS4Aj7qA6wSasMZYW3CTMJi3n2ti pjjH5_n2ETLumKthDxH7R1vhd.isU68yFHlBJkYxg1iiw_uul_RdNRen_7NHYWMlDReyk2o7cKKY az240jS1pcRzPz5QJAGv18K_tHYGAfvN9BrfThGtq92XyOcpCD8oh3BXht4R7U7.btGNf9D1gCZr 6EeuqpOX6ogo.zCdLtFubphTNLHzAVIhCBY1KMwzc3gvDr6odTRn82KG7BfPYBltsZqjlcQzq52v ccRpERA-- X-Sonic-MF: X-Sonic-ID: ed051316-1402-4212-a1da-9ffe79f02375 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Sep 2025 05:02:07 +0000 Received: by hermes--production-gq1-7bfc77444d-vcv5p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3898a3397c3f4b34bc61bc9f02a39b06; Mon, 15 Sep 2025 05:02:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Git and buildworld running at the same time From: Mark Millard In-Reply-To: Date: Sun, 14 Sep 2025 22:01:54 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQCZB1dVGz3JNb On Sep 14, 2025, at 21:16, bob prohaska wrote: > On Sun, Sep 14, 2025 at 02:50:03PM -0700, Mark Millard wrote: >>=20 >>>> At the moment git occupies 1.3 GB RAM, 505 MB swap and 10-15% CPU. >>=20 >> The above "1.3 GB RAM" seems odd for a RPi2B with >> only 1 GiByte of RAM. The ps columns are: >>=20 >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME = COMMAND >>=20 >> RSS is a RAM usage figure (768984); VSZ is Virtual >> SiZe (1346480). VSZ can be bigger than RAM+SWAP for >> the process, as I understand. (Making simple >> arithmetic problematical.) >>=20 >> Was the "505 MB" system level swap usage, instead >> of process specific swap usage? >>=20 > The numbers came from top's SIZE and RES columns, RES(ident) is RAM use. SIZE is virtual space for text, data, and stack spaces, according to top's man page. process (RES+SWAP) <=3D process SIZE generally. 1.3 GB might be SIZE on an RPi2B --but can not be RES (or RAM) on an RPi2B. May be things got out of place? 505 MB of RES and 1.3 GB for SIZE? (The values would be consistent.) > thinking SIZE was total memory and RES was in ram. In > hindsight, I've no evidence for that interpretation. >=20 >>> If I gather correctly, it looks like at times, when it >>> will be a notable time before activity like building >>> software, something like: >>>=20 >>> git -C /usr/src/ gc --no-detach --auto >>>=20 >>> would be appropriate. The "--no-detach" avoids it >>> running in the background so you know when it is >>> running vs. when it finishes. You would want to do >>> this often enough to avoid fetch/merge --ff-only >>> or pull from doing such automatically or having >>> a lot of accumulated pending work to do. >>>=20 >=20 > Knowing that a git pull will be followed by some > background work it isn't really a problem. I was > fooled into starting buildworld before git finished, > now I know enough to let it finish. However, for a > script the --no-detach is a useful addition, at > least when confident git will finish successfully. --no-detach and --detach are not "git pull" command line options but are "git pc" command line options. maintenance.autoDetach can control the behavior of commands that do not have --no-detach and --detach command line operations. If unset, then gc.autoDetach controls such (if set). If both are unset it is as if they had been set to true (so: detach). >=20 >>> There is: >>>=20 >>> gc.autoDetach >>> Make git gc --auto return immediately and run in the = background if >>> the system supports it. Default is true. This config variable = acts as >>> a fallback in case maintenance.autoDetach is not set. >>>=20 >>> and also: >>>=20 >>> maintenance.autoDetach >>> Many Git commands trigger automatic maintenance after they = have >>> written data into the repository. This boolean config option = controls >>> whether this automatic maintenance shall happen in the = foreground or >>> whether the maintenance process shall detach and continue to = run in >>> the background. >>>=20 >>> If unset, the value of gc.autoDetach is used as a fallback. = Defaults >>> to true if both are unset, meaning that the maintenance = process will >>> detach. >>>=20 >>> So you can force it to not detach automatically. >>> But, then, you might have a long wait for the >>> command that added data to complete: >>>=20 >>> # git -C /usr/src/ config maintenance.autoDetach false >>> # git -C /usr/src/ config gc.autoDetach false >=20 > I'm a little confused here: are the two commands above equivalent > in action to > git -C /usr/src/ gc --no-detach --auto=20 > when used in a one-line script? =20 maintenance.autoDetach and gc.autoDetach provide the default. --no-detach on the "git gc" command line overrides the default for that "git gc" command. Part of the question would be if you want to have to remember to provide the --no-detach vs. if you want it to be automatic. But there are commands with no --no-detach commnd line option that are still controlled by maintenance.autoDetach / gc.autoDetach . I'll note that there is also --detach for the command line, which again overrides the default. =3D=3D=3D Mark Millard marklmi at yahoo.com