From nobody Mon Jan 22 13:23:37 2024 X-Original-To: dev-commits-src-main@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 4TJWBh6nNHz57tv7; Mon, 22 Jan 2024 13:23:40 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TJWBh6F05z41dJ; Mon, 22 Jan 2024 13:23:40 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705929820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CTxbSZ125kEyAUrIvsOS5Ehn1E3U637pAdUdMBDUB+I=; b=wxk1AQBJzSteJPE5wNXbTxieHs82PUMXcaa8bEIEDLcpXuUpE+OJNUAG3Y6juXMTtOl7pY w9vhOxF8H3UyoTurVUCCPv4yY2QjYZ8CZF1LFA8YWAyfuRgGEkHMQrgaKSdjtsgwZYNoQU W4IrOaj6ehhuI436P/ERFASUv2rfZB0fkxt9MM/ZaL1tobCCZwmdTX1c+bNlcHG7MD3yDQ cLe1v+sQkXxaTB5jlOto/hbn2U6tZHtgC/jWsydDFcrGfpyDJJFooJcPf80vq8Tg0zAYrn T4+aPWj60va2ouOr6RKQ1P8TxcJAbFrdkS1e7EBNvr0Ta3Y1vg7h4mYXjXGAgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705929820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CTxbSZ125kEyAUrIvsOS5Ehn1E3U637pAdUdMBDUB+I=; b=k3C6DZPRNVCF3shN6u6DrSAIqJZ+25dQ8mvMF9ANgXvcinCZOB2VVzykbI53GDyDy1Z4dt fWyLymzuVd9Wu4JKGEOjPQnYUtWINV+S+fNnYDyB5PjIhSqPVQENxgpTZGx6xgCudKrowF 6xH5tR8FKY0S1Kr+Y8P34VO9tj+4jQ6fEQBopGw95U9cxSjvYEv3or1r/Tzo6kUd2PTtAt Sbb9G1YRq3Ip7qgl4HKdsuEuOIyAgnRt3fXjPbjgYKXtIJU74HRWidqwBKo3g+tUwThIRv cQY97bg8uPTSjkMgZ1e/HYgxZmet5QvYQRDYC2yAc09x7p0YSrnD4CBSoPKoag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705929820; a=rsa-sha256; cv=none; b=q5yj8EiB9FOJQQ0V2bFylSwIkb/rTdOLREYG+CoTxSkjg08UsoBxvq0Yk/nXtlhCPQqj0t qgGxEEBmnv8TjMNptpqLxHKw2XVvXHFLixKOOl3un5iYRx0teNbPjtTj3Q5ehPrryAVLc8 7Dpzp9ItA8++X6LmoczMygds09+xUYX+DYzfhm8kSKtNf4Sgu1LiN9GDX5rtkQ4LjOv9R0 i9ZVnPawfmVSs+FKCIk9AaL7XJGIL17Qe89GW4wwJhD2/MvUFa51PhlKbBhkhXEZ1dxY9x Rzb4ZxjWieFy4nXHwE3Hyng4B4xjY88WBvvkI3sxBEpd0iqcCswPENnPJdSETA== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TJWBh4dhszb7D; Mon, 22 Jan 2024 13:23:40 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 05BB19F356; Mon, 22 Jan 2024 14:23:37 +0100 (CET) Date: Mon, 22 Jan 2024 14:23:37 +0100 From: Baptiste Daroussin To: Mike Karels Cc: Alexey Dokuchaev , Jessica Clarke , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: Re: git: 636592343c3e - main - tmpfs: increase memory reserve to a percent of available memory + swap Message-ID: References: <202312191534.3BJFY3fo030908@gitrepo.freebsd.org> <04794665-EFCA-4E89-9956-B18684898C9D@freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04794665-EFCA-4E89-9956-B18684898C9D@freebsd.org> On Mon, Jan 22, 2024 at 07:15:22AM -0600, Mike Karels wrote: > On 21 Jan 2024, at 21:48, Alexey Dokuchaev wrote: > > > On Mon, Jan 22, 2024 at 03:27:57AM +0000, Jessica Clarke wrote: > >> On 19 Dec 2023, at 15:34, Mike Karels wrote: > >>> commit 636592343c3ec0feb61a4d8043676381384420dd > >>> > >>> tmpfs: increase memory reserve to a percent of available memory + swap > >>> > >>> [...] > >>> > >>> Add sysctl for vfs.tmpfs.memory_percent and the pre-existing > >>> vfs.tmpfs.memory_reserved to tmpfs(5). > >>> > >>> PR: 275436 > >>> MFC after: 1 month > >>> Reviewed by: rgrimes > >>> Differential Revision: https://reviews.freebsd.org/D43011 > >> > >> I just got: > >> > >> make[6]: Could not create temporary file /tmp/makeDl4i9S: > >> No space left on device > >> > >> after doing a buildworld -j4 on a 4 core, 16 GiB system where /tmp is a > >> tmpfs, with the prior buildworld having taken me past this commit, > >> which I strongly suspect to be the cause. Whilst I understand the > >> motivation behind your commits, this is a sad regression to have; it's > >> not exactly a particularly strange situation. > > Bug 276402 is about the interaction of this change with ZFS ARC, which > seems to be problematical. I spent some time investigating yesterday. > Depending on the dynamics, I get different results. If tmpfs grows, > the ARC will be reduced if needed. But if the ARC grows to the point > that tmpfs sets free space to 0 or quite low, attempts to write to > tmpfs fail without any reduction in ARC. > > Jess, two quesions: > > 1. Are you using ZFS on this system? > > 2. Can you try with vfs.tmpfs.memory_percent set to 100? > > > FWIW, I've seen two people complain about this last week, apparently > > this kernel OOM protection doesn't work very well. :-/ > > So far, I have only seen OOM kills when memory + swap are quite short, > with a tmpfs memory_percent above 95. But with ZFS, it can happen > when the ARC could have been reduced. > > I will investigate more today. If I don't find a way to resolve this, > I'll probably commit a change to set vfs.tmpfs.memory_percent to 100 > by default, at least for now, and if that works around the problem. > This is easily reproducible with poudriere, if you try to build some ports/packages which are big memory consumers, for example any chrome variant or just lang/rust, I have a machine with 64G of ram and it is impossible to get lang/rust build in poudriere (USE_TMPFS=all) without setting vfs.tmpfs.memory_percent to 100. the poudriere dies with plenty of no space left on device. Best regards, Bapt