From nobody Mon Dec 04 19:50:15 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 4SkZ5N5gHfz52krp for ; Mon, 4 Dec 2023 19:50:16 +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 4SkZ5N4Vg6z3bTB for ; Mon, 4 Dec 2023 19:50:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701719416; 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=/1GcarpPXp/KxgH4ybcX4WAMpn/M9uZxA+DgfpEv8cY=; b=Z0ZVZD0YkUWiqCNNe/twas8krHWXjKjIDKqTDGtMsoWSYP77CIpogZVuHkbThJoVtq9INa X6fQNoNBKJ3SOZ4g1OfR/odeItyjRR7D1IKiasOdGqKgY49H2s/ln2nBqJ2fLBnTfJfT+4 ysMmqf+bZgGfYOe0qAgpZq1idsLLD5YFJr4UwsBngBJAsOoe/k2AugkzIL2mq/+L9Ei3Oi +cJbPByedn9ttSkVoBs5zHU5GpvS0XAUy47n9THLX5qSO1g5BRA6ZR96TR7XjGgwD1vxyI 0TDjgUOqjO++NRXQYYy0yAN0YG5J2BRMmCtU7pJcM5VRPfYh/fuGi12IP896Ew== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701719416; a=rsa-sha256; cv=none; b=i1nqWyb4kdO7uUBq3GzqOkYzN/btl9YprBnzV3hlCp1cwj7K4LkpPfSqSG+L/Lypou2Xuw c8tXJKI0q3p+v7fdaejE29oSaGa+Yqeu4XUkx+22+bwG02+d0AX/JjlQKWGG0D74924GUC 8bGsZYwcSWtHxSpkD9IqUJIZSUx5nyBsoZF0+f6AlKJIGxVflGy/UW7lvRBHyh3p9bY6lu A8wBUGbnfQmR1cqaPzM4Yd7gNJoH5dCVumu4vsJCJDlqlKV/CCYoKltB5YSq4qG1ITPjTK fgWQaF/YoBEZfZ1HJNjhJif40Fre//9Xu5mmM1ckmMsoGXciRpSVNIh9h3iiTQ== 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 4SkZ5N3Y3fzfqT for ; Mon, 4 Dec 2023 19:50:16 +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 3B4JoGkU021519 for ; Mon, 4 Dec 2023 19:50:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3B4JoGBx021518 for bugs@FreeBSD.org; Mon, 4 Dec 2023 19:50:16 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: Mon, 04 Dec 2023 19:50:15 +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 #7 from Mike Karels --- (In reply to Konstantin Belousov from comment #6) > VM (alomst) always ensures that there are several free pages. More, it e= ven > typically manages to free several pages in reasonable time. Except for when it doesn't, e.g. when swap is filling up. It also may requ= ire killing processes in that case. Given that tmpfs is supposed to limit to "available" memory, killing processes means that it has overshot. > Now that I formulated this, I think that for tmpfs a reasonable approach = would > be something in line of per-process OOM: try the allocation, and return E= NOSPC > if it failed, with some criteria for restart. You might look at vm/vm_fa= ult.c > vm_fault_allocate_oom(). I'm not sure, but tmpfs may go down that path if it can't get a page in uiomove_object(). That may be desirable in case of transient memory shortag= e. I don't know what happens if it fails though. But when swap is getting short= , it seems better to fail before that point. I really think the default limit for tmpfs is overly aggressive. If it rea= lly tries to take all of available memory + swap (less a small reserve, current= ly 4 MB), processes will be killed and the system is likely to require manual intervention. In the case of a transient memory shortage, blocking for memo= ry is fine (and may be done already?). I am now looking at a reserve that is scaled on memory + swap space, e.g. allowing tmpfs to use 95%. The percent= age is controlled by a sysctl. This still includes a check for available space= in the write path. (There is already a check in the create path.) This seems= to work fairly well, based on limited test circumstances so far. --=20 You are receiving this mail because: You are the assignee for the bug.=