From nobody Tue Oct 29 19:27:12 2024 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 4XdKyT3HYzz5bpqN for ; Tue, 29 Oct 2024 19:27:13 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XdKyT0K2wz4GYX for ; Tue, 29 Oct 2024 19:27:13 +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=1730230033; 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=ULk0W4KCxB5U37qSi4g4Wkg72li04j0j5waNAiahP+E=; b=AbeEeysc1V3ZjEnS1R3kXhcQAPxmTx/zk8vx6gZDZqeZFt1oKL8a9Zcm0nSf80UjZLTi7u Rtsx3eogRjaZQRJUPKlfb2JDfhgjLNGiny+81/tV6EYs/LLFdNc7fDuPdzKiwgmWvx8Wi3 whUj4JEoXrWnRAEhLINoaBPqoKsTivEmlE6vCIJetkqFx+O+3wY+2A48M3/PFpqNEJNYd+ umSFKxAhcRpzf7azHXWK0IimEOhTb6RBOW/RHF4VBrMlSbGi4x4xj0o5+i7N3fnqIejVWX CDil0DNJeUObWTpBwv8c5eakj5+AIAFIm3vfw3K+/95BySinNmxEd1wlc+7dBw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730230033; a=rsa-sha256; cv=none; b=lc0HrWV72TY+CWH3DnIt8UhMePD/oGIdgHWt7SqlYUI4Va2VzVexifLrCTUKZ2C+Th5TOc ZTvrRQ3tBS78dWzyM/fJIR/KQAZWsebHEswwR5F19DKfeq5hw4eUPg9vQFyTato2FR4G+p kUGRdOqFfS6EwneJaHYUVwfu3MqRKMEr5bePYU3/KXsRGT1lQC6T6Tk7gyC3XqU/djbA6S N+RBGlRw16rEKSm8M/AP/y8woyvUqBx2j9UMxyO+tMMZg55dX0IgZpE1YARa1f7U6fhVuM 659uCtddu7q2zP+UMiFahi/VPK+og0PZX7Qyszej3tdpfOyy4FUFAhWNAbRAkQ== 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 4XdKyS6w1vzcj9 for ; Tue, 29 Oct 2024 19:27:12 +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 49TJRCg5062967 for ; Tue, 29 Oct 2024 19:27:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 49TJRCXj062966 for bugs@FreeBSD.org; Tue, 29 Oct 2024 19:27:12 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 280846] Low memory freezes / OOM: a thread waited too long to allocate a page Date: Tue, 29 Oct 2024 19:27:12 +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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: henrichhartzer@tuta.io X-Bugzilla-Status: Open 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=3D280846 --- Comment #66 from Henrich Hartzer --- I'm glad that you've been able to reproduce this. It's nice to be able to s= ee the usage in top as well. I'd like to share a few thoughts/anecdotes on this. When I killed Telegram Desktop my laundry dropped about 400MB. In Firefox I cleared cache and it cleared a couple hundred MB from laundry.= I need to test that some more to get better figures. I'm wondering if this is Firefox specific, or if there's some shared compon= ent that is causing this. This may be far fetched but I am wondering if there i= s a Linux, maybe glibc behavior where you can mark a page as no longer needed b= ut useful if it can fit, that isn't translating to FreeBSD. I could see some page/cache data that would be nice to hold on to if possible, but if there's any memory contention could be readily be jettisoned. Perhaps those are our laundry pages? Just speculation from someone who doesn't know a lot about h= ow allocation works. After running on UFS for a while, I feel like the OOM behavior is much more predictable and faster than with ZFS. Under ZFS I was getting hard locks fo= r a while. With UFS, it seems like it'll usually resolve itself (killing someth= ing) in around 10 seconds). But with ZFS it could lock for minutes with this OOM condition. I'm not sure why that is, but it's nice that when I run into the= bug it resolves pretty quickly if I'm not able to "catch" it in time. --=20 You are receiving this mail because: You are the assignee for the bug.=