From nobody Mon Jan 22 13:15:22 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 4TJW1G0n0Tz57tZs; Mon, 22 Jan 2024 13:15:30 +0000 (UTC) (envelope-from karels@freebsd.org) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TJW1F5yh6z415H; Mon, 22 Jan 2024 13:15:29 +0000 (UTC) (envelope-from karels@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40MDFN8E035918; Mon, 22 Jan 2024 07:15:23 -0600 (CST) (envelope-from karels@freebsd.org) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id XSgiIGtqrmVMjAAAs/W3XQ (envelope-from ); Mon, 22 Jan 2024 07:15:23 -0600 From: Mike Karels To: Alexey Dokuchaev , Jessica Clarke Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 636592343c3e - main - tmpfs: increase memory reserve to a percent of available memory + swap Date: Mon, 22 Jan 2024 07:15:22 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <04794665-EFCA-4E89-9956-B18684898C9D@freebsd.org> In-Reply-To: References: <202312191534.3BJFY3fo030908@gitrepo.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 X-Rspamd-Queue-Id: 4TJW1F5yh6z415H X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] 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. Mike