From nobody Thu Dec 7 18:42:24 2023 X-Original-To: bugs@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 4SmNRh2LW8z53Qlk for ; Thu, 7 Dec 2023 18:42:24 +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 4SmNRh11WKz4gkH for ; Thu, 7 Dec 2023 18:42:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701974544; a=rsa-sha256; cv=none; b=hNHb2Im5aw1RbN6Orz964DN73e9u43jExjEd/P58KRz0PtRdhloGgrCoyBad730ZWzKZNv /EqpmotcnsDQbBLuyO0C0qHyTi08C5wdpUQeywYvKCWOsFp4t6F8QPHR5vMJncptovfB0z km2wnZE+gjpoIC4DeT2XXUkEwEoUrlRgvSTnXrE2tb2so8saJ/eUeYE+/A2UItI7SS7Lr/ M0c5l6iwYUwd2oi+W4qmgNYTIbLm3dnSb3xt1RwQ4XCJTWzt+3VzC4Bcccmd2UGjFvcrWF ELpsQfiwoGrDl2WzdKf6wT4fD82HLVafdAnSoLesPt3rihOqDOT3tfflCpMuHw== 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=1701974544; 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=ul0L3nQ6uqYI2lKzJNr0Vs/PyHAhil4PdQ1GSf1uDSg=; b=LzWa6IJwTA47Emu5hyInQGnhN/U4fN9YW9T5+bY3juN8eo9pcsTIKtz5TBUv8vltHtQ4hB nCLAbkPMFTaMaG7vMJyV3oD3jas8NF2WoqitkkU7rGywxqWIa890ZxY3LpcC7tzLxGVwPp gt7kH4Aw38KY9X+Py3Y4aibfJIdkWh1ky368pW3aktnmvf+jGF0KzpbEKoiWb0P1RcdcrW E+R6CjS4iFl/5CXEP08p2ynT9HPe9vp9PhlCSIQ2EKWUHrApfJ0guO+5TdzjXSkbvLMM08 WshGjXFO9kAWdMVZcdJ8c03Z0NPtyDsnBXVIewOV4z3bn+zpc1xN2rnTO0zsVg== 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 4SmNRh03dYzp04 for ; Thu, 7 Dec 2023 18:42:24 +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 3B7IgNk1091884 for ; Thu, 7 Dec 2023 18:42:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3B7IgNMT091883 for bugs@FreeBSD.org; Thu, 7 Dec 2023 18:42:23 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: bugs@FreeBSD.org Subject: [Bug 275436] tmpfs does not honor memory limits on writes Date: Thu, 07 Dec 2023 18:42:24 +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: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: karels@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@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: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275436 --- Comment #9 from Mike Karels --- (In reply to Konstantin Belousov from comment #8) > Proposals to limit max tmpfs page uses to some percentage of the total of > memory and swap would not work. My proof-of-concept does not use total memory + swap. Instead, it computes= a reserve which is (100 - memlimit%) * (free memory + swap) at time of tmpfs_init(). This seems to work out reasonably in my test cases so far. I need to try with mapped files too. I'll attach my current patch. > There is simply no reasonable answer to question 'how to limit tmpfs phys= ical > memory consumption' without knowing the system load pattern. There is no perfect solution, that is true. But when memory + swap is low enough, allowing tmpfs to proceed makes bad things happen, like killing processes and hanging the system. Backing off a little makes things better= in at least some cases, which seems worthwhile to me. And tmpfs can report a failure (ENOSPC) without being killed, unlike processes touching memory. Y= es, a compile may fail, etc, but at least that is related to the shortage. It seems bad if writes to /tmp by an unprivileged user cause root or other important processes to be killed. --=20 You are receiving this mail because: You are the assignee for the bug.=