From owner-freebsd-current@freebsd.org Thu Jan 28 01:33:11 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B91C54F0DEB for ; Thu, 28 Jan 2021 01:33:11 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DR2zV0Fglz3tcm; Thu, 28 Jan 2021 01:33:09 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10S1P9xr007203; Wed, 27 Jan 2021 17:33:07 -0800 Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2170.outbound.protection.outlook.com [104.47.55.170]) by mx0a-00273201.pphosted.com with ESMTP id 36a8y1cd7d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jan 2021 17:33:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MIP/Eaeyye/u7A2kc1nMIzngQu9GgIbMo84NSisp9qqbTmX6xjCvfR5SvC1GxOK4kp+RwoEq5sqjDo8tj0ng0VI/vJbVO20afTU8ZJgqrkkdeaF1dMcCB9gj/Qm+t9/CZkkHE/YNBC2TJfgYx8EV5XhzImm0KzW0EHJY3Znzo9FBI5bvFZ0BjRjUC1n27UCL1wKynyYDcJnqb1nuY4nds95BHXfgRtj/ZDTtgqVGEMjKh38LD+luxMAtzQ1R/+gDuKaM2sb6Y6pcSby8AEH440W0YVt1g/Rswje1Ys5gYL1ueUDQFAPJSWbOAMZSAyPciKrksJeexQbDhImKiyn6Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9yybdvoslTOkJvZQBM28RVauHGhXPj3iwu2OjaRluno=; b=R1nEh9F07rI/AnZSmhg7Z40W6Tvv72P0mAVJhsNRmi/RQLUiImyNnbT0GqA2KGNO7wmYyymdq989GNeMC0vE/S8DvJfCCz0s3r7a6P9OJYnJWzaSOV4oPu2r47KOTymM2Ar3jymp16vXChyvoeGcUcg3iFDiarEskjvnNFE0bfn+q9k5/CS7P4X2ScB+3xRnOulPTA+SBuyDWGm2SQjysqoEHLIWw57vomaNPIxvshNCO0Lb+wuHv0uPRZImjLPcTpwFDnTcQUL+HDQopdeLk8E1zmFiq3PQW0nCnoRPHM4/TD0+Cy4tzKyEVEfvqqvf13DPc6REkjBzdkMC+2NiXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none Received: from BN8PR15CA0035.namprd15.prod.outlook.com (2603:10b6:408:c0::48) by SN6PR05MB5215.namprd05.prod.outlook.com (2603:10b6:805:ef::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.5; Thu, 28 Jan 2021 01:33:04 +0000 Received: from BN8NAM12FT005.eop-nam12.prod.protection.outlook.com (2603:10b6:408:c0:cafe::51) by BN8PR15CA0035.outlook.office365.com (2603:10b6:408:c0::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16 via Frontend Transport; Thu, 28 Jan 2021 01:33:04 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by BN8NAM12FT005.mail.protection.outlook.com (10.13.182.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3805.6 via Frontend Transport; Thu, 28 Jan 2021 01:33:04 +0000 Received: from P-EXBEND-EQX-03.jnpr.net (10.104.8.56) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Jan 2021 17:33:03 -0800 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-03.jnpr.net (10.104.8.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Jan 2021 17:33:03 -0800 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 27 Jan 2021 17:33:03 -0800 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 10S1X1J3011052; Wed, 27 Jan 2021 17:33:02 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 2FF5728A71; Wed, 27 Jan 2021 17:33:02 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 2E7B228B4E; Wed, 27 Jan 2021 17:33:02 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> Comments: In-reply-to: Mark Millard via freebsd-current message dated "Tue, 26 Jan 2021 16:00:05 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72122.1611797582.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2021 17:33:02 -0800 Message-ID: <73088.1611797582@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef48cbfd-b43c-4685-5d2c-08d8c32ca880 X-MS-TrafficTypeDiagnostic: SN6PR05MB5215: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tzM37lhUlRQ1IsrhDMYnP3m9Bqk6JICyYbpUm9XLLkiZhmQara4pLa3eP958HgNnv6q/+IMzuBsP5CHCGf1ZPH/F5nnJNyRNe2w3eCKqgQVkEDn3fLEoMhcMIDnHviXJQqqWvi/BCXyraSAVXROoF1tFFxxye3G50ETZvfYunVh2NNjjwpIAlGM21ZGkA0d1XnnGe9RGq+pyAj16yrEiVcn7bg+p92XMjXgJJYL0JdequI+SgRmCvZPnWOpcxjf9uadA08OKkbVxVb1d3SNug+9AVZCJRCZbYK6NFtOXGxf03UKxdmHxHFK7uau+KdBVcH34MWju205h+mbguVI47q+Ed8ZrC1SewaYUSIT2FCoJwKYjhQxAR8pYRGEzVt1Lo0mJVkzwKV3okwVSwerFS6bKslzxW7Ctt+XjNhre7Yw7Pmxc4TnQ+E3pbVkn+SXgnQkE2SUx5HxxdnXHiWNTLHsSD73Ch26LqfflvxSO1p7yd4zs/7V8FsvWMpKk9XHvd/taMuD5lgkWJ4GiS+V/tACHorZA1wWdFPCRi6ALGmT4DE+iZVKW26pGsoUIVpPfJs0QUcsRkLCdvitEJNL0pdAQH7/rBu26Rpe2UKR8lnHjyt415fRWCiZ4XW7HsGlx X-Forefront-Antispam-Report: CIP:66.129.239.12; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:P-EXFEND-EQX-01.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(136003)(346002)(39860400002)(376002)(396003)(46966006)(7696005)(82310400003)(6916009)(107886003)(82740400003)(186003)(7126003)(8676002)(26005)(47076005)(6266002)(4326008)(86362001)(356005)(5660300002)(2906002)(336012)(478600001)(316002)(70586007)(55016002)(9686003)(8936002)(70206006)(81166007)(54906003)(83380400001)(36610700001); DIR:OUT; SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2021 01:33:04.4358 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ef48cbfd-b43c-4685-5d2c-08d8c32ca880 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT005.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5215 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_10:2021-01-27, 2021-01-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 impostorscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 lowpriorityscore=0 spamscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101280005 X-Rspamd-Queue-Id: 4DR2zV0Fglz3tcm X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.84.65.16:from]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:208.84.65.16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; SPAMHAUS_ZRD(0.00)[208.84.65.16:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[11]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[208.84.65.16:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 01:33:11 -0000 Mark Millard via freebsd-current wrote: > >> Given an already built, installed and booted system version, I've > >> noted a big difference for META_MODE in 2 rebuild contexts (no > >> source updates involved): > >> > >> *) Prior buildworld buildkernel, installkernel, installworld, boot > >> presumed before (A) and before (B) below. Yes installworld is going to cause problems unless you tell meta mode to ignore everything outside of the src/obj tree. But even that isn't enough as you note below. > >> So I used make -dM for the commented buildworld buildkernel lines, lo= gging > >> the build output and later diff'ing them. > >> > >> Result that I noticed? Lots of lines uniquely from (B)'s case, ending= with > >> one of: > >> > >> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tm= p/legacy/usr/sbin/awk' is newer than the target... Yes. That would be expected. I think Bryan added some knobs to mitigate some of this. grep -n META.*IGNORE share/mk/*mk might be instructive. > >> Many/most/all(?) of these seem to me to be unlikely to actually need = to > >> contribute to what needs to be rebuilt (just based on being newer). S= o > >> the option to ignore (some of?) them could be useful in making META_M= ODE > >> builds quicker. Yes on all counts. That's why bmake provides a number of knobs to ignore such things. They are listed in the man page in increasing order of expense. One of the risks of the sort of introspection meta mode does, is delving too deep (like the dwarfs ;-) The .MAKE.META.IGNORE_* and .MAKE.META.BAILIWICK variables help to contain the potential insanity. > > The following from one of the .meta files makes the point that rm use > > in the example is unlikely to be important to needing to rebuild, > > despite it actually causing a file rebuild. Nor is the specific echo > > command listed relevant. Only the "ar" command is: > > > > # Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd6= 4.amd64/lib/libc++/libc++.a.meta > > CMD @echo building static c++ library > > CMD @rm -f libc++.a > > CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o > > -- filemon acquired metadata -- > > # filemon version 5 > > # Target pid 22471 > > # Start 1611359217.214996 > > V 5 > > E 22961 /bin/sh > > R 22961 /etc/libmap.conf > > R 22961 /var/run/ld-elf.so.hints > > R 22961 /lib/libedit.so.7 > > R 22961 /lib/libc.so.7 > > R 22961 /lib/libncursesw.so.9 > > R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > > F 22961 22962 > > E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/t= mp/legacy/usr/sbin/rm > > The timestamp on . . ./tmp/legacy/usr/sbin/rm is not > > actually relevant to if libc++.a needs to be rebuilt. True. = If there is nothing under .../tmp/legacy that should be counted you can just: .MAKE.META_IGNORE_PATHS +=3D that path which would be the cheapest option. If however there are things that should be considered you'd have to use a much more specific list of .MAKE.META_IGNORE_PATHS or perhaps something like: .MAKE.META.IGNORE_PATTERNS +=3D */rm would ignore an rm binary regardless of where found. worst case you might need something like: # realpath .MAKE.META.IGNORE_FILTER +=3D tA # ignore anything here .MAKE.META.IGNORE_FILTER +=3D N*/tmp/legacy/usr/bin/* Unlike .MAKE.META.IGNORE_PATTERNS which is a list of patterns to match the goal with .MAKE.META.IGNORE_FILTER is to reduced to an empty string paths to be ignored. > > Of course, the structure also point out the judgment > > is specific to understanding the sequence of CMD's > > listed above. Only a hack of ignoring, not recording, > > or commenting out the filemon lines ending in > > /tmp/legacy/usr/sbin/rm would seem to avoid the @rm > > handling issue. Such might well have its own risks. No hacking needed, there are a range of knobs to help. > Just for reference for more about the sequencing involved: > = > Looks like in my example various . . ./tmp/legacy/. . ./*bin/ > actually are links to files in: > = > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= bin/ > = > and the later after-install buildworld "Rebuilding the > temporary build tree" step leads to the updated dates for > files in that area, updated via the code that reports: > = > Linking host tools into /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src= /amd64.amd64/tmp/legacy/bin > > So the prior installworld leaves updated dates and the > linking to those installed files makes > . . ./tmp/legacy/. . ./*bin/* have the newer dates show > up for the legacy paths as well. > = > In turn the dependency tracking via META_MODE uses the new > dates on . . ./tmp/legacy/. . ./*bin/* files to cause > rebuilds of more materials than if installworld had not > been done. > = > It is not obvious if Bryan D. would find the effort to avoid > this worthwhile for the contexts that drive FreeBSD's build > environment choices. For people that use installworld and also want META_MODE it would seem some additional IGNORE work may be beneficial. --sjg