From nobody Tue Apr 02 17:08:46 2024 X-Original-To: fs@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 4V8Dqw1D8zz5FHjJ for ; Tue, 2 Apr 2024 17:09:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V8Dqw0CWSz4gSR for ; Tue, 2 Apr 2024 17:09:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1712077740; a=rsa-sha256; cv=none; b=GXyuIR4ON893XG6a9XLgUiTY+YGEmJsv/zR5ATj0xaASCkmXwmxyCVd1Qm3YmAqm31UUB4 YXjp716Wu9TAmSPHKjtGre5CCPb+4Clj9l+gkuLSqmIxWu+pRQvGHaIVOYrRnjLHV/87UC Xh8WeSN9B7LQKT4dn5XYbRWquZcB9awatwynVFkYIqgiI7gEcF3heH3NSgE4BpmNAjbGTO JyttJuhqvHOimXN5PbZZ3CML0ho3gxRRQNIwzKCcU6ns0cmxiInWyZl65MolROx+lovShQ OluazbpVMOHryNRQYLtCnPeb/YYfLI7Yg3aLE+l9SKemsjuj7wB/f/Fnsi5Jwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1712077740; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zusPozdsfx6CGYUkPD8l1BqeBo3BFgBKSWVJKRKPsz0=; b=jkD6ul4jQCVwntMxpY/7AKsCZ615tA1w7H6asGpx7WgNG4/tbYi+Ng5cUdjskzzeAlPUrr sQk1YmZQ6bi2fj3Yd+IY90ml9oJGSDhag98GrZI4wCJB+UCsOnckV3lw0UTcDLQAZ9onZe GPBo1kyCSmvxpteoY00SfF+nuoMdTnCDKlRYaTDa+RK3fR9oytlbzKfe971pq+sRtBYdUf gapFiDlMXmXNxdxZOrVdwuiVRWcSlZ4UdDd4U51+PfOHOerY7P0wfiNaB6WioPZ1tFrVBM JzPpJ3LWvnlp5izmadcAebB3GnjOLUKPZp20jaItE72PbLVKG0M3zpMpx5h5mA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V8Dqv6wdDzy0g for ; Tue, 2 Apr 2024 17:08:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 432H8x4o068593 for ; Tue, 2 Apr 2024 17:08:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 432H8xC3068574 for fs@FreeBSD.org; Tue, 2 Apr 2024 17:08:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 275594] High CPU usage by arc_prune; analysis and fix Date: Tue, 02 Apr 2024 17:08:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275594 --- Comment #104 from Mark Millard --- (In reply to Anton Saietskii from comment #102) I'll note that rust builds are massive users of temporary disk space in wrk= dir, even for single-builder/single-make-job builds: I've seen nearly 30 GiByte = and have seen well over 20 GiBytes for a long time. When USE_TMPFS=3D effective= ly includes wrkdir, this competes for RAM+SWAP via the TMPFS use. The highest usage is towards the end (packaging). Another issue is that historically when the builder completes, such TMPFS s= pace use stick around until/unless the specific builder starts another build. I historically have provided lots of SWAP so that RAM need not cover such a= nd RAM+SWAP had lots of room. But there is also the poudriere.conf technique of: # List of package globs that are not allowed to use tmpfs for their WRKDIR # Note that you *must* set TMPFS_BLACKLIST_TMPDIR # EXAMPLE: TMPFS_BLACKLIST=3D"rust" TMPFS_BLACKLIST=3D"rust" # The host path where tmpfs-blacklisted packages can be built in. # A temporary directory will be generated here and be null-mounted as the # WRKDIR for any packages listed in TMPFS_BLACKLIST. # EXAMPLE: TMPFS_BLACKLIST_TMPDIR=3D${BASEFS}/data/cache/tmp TMPFS_BLACKLIST_TMPDIR=3D${BASEFS}/data/cache/tmp that avoids the TMPFS based wrkdir space use just for rust. (Of course, one needs the actual storage space in such cases.) With rust avoiding TMPFS wrkdir use, I've observed llvm18 taking more RAM+SWAP than rust, even with some llvm18 default options disabled. (I do not have a list of packages with such large wrkdir space requirements but would not be surprised if there are several more around, some possibly not being compiler toolchains. But I do not normally build a wide variety of large-builder software that are not compiler toolchain related.) --=20 You are receiving this mail because: You are the assignee for the bug.=