From nobody Tue Oct 29 21:13:32 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 4XdNK86hCxz5bvsP for ; Tue, 29 Oct 2024 21:13:32 +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 4XdNK81z3Rz4WbP for ; Tue, 29 Oct 2024 21:13:32 +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=1730236412; 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=DfnZ+RIqFQPpT4/M4Am1hyo9mDauEz34jrXKk4QnOgo=; b=WotZZrDYjuMx3vSq95vw5VQZnyAI4gMO8+mbNkufv+G3hdMETKeJ/WSPLkkE/IPOAy+CJk ZJ42rOf5Z2iYKreD9Y/+i4HTBt4rNAuv9t4ZpDnUzMriMjc6h3nhQ3MCa/esFZCzvQJ1B0 bUJES6avxGniQgfAUgENCI3qrH5MOH25Q3APtYDa3ziD6I+Jc01kaf9ZVhdeTn3B3WdQT2 jLIqxnFtdCYcKXA9C8ZbxF6MKT3y7QgxhC+23EvVktPERB/h5yxRpN1zerDwq10rUds6Ee rmbTxbJNqnoA1eAK6A6qC4A3lxMHNWmdyzNAdbnKA/NkWj+b4qkM/RfZBEM54w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730236412; a=rsa-sha256; cv=none; b=yIIEcro6o1FwTHFDKtLZIUo4eyNA2dWEFIEhmsm7pN0YW/DHWffW/puFijwR4voZ6m/GOi O2yLj6J6BrYSAQZEbXQ1NEu31qmtUB17ZdJUzXL9qJ+tItO1h5N/yttJl62qYEEqSSkgzT ySDdoh7sBvj/xwrqoMX8bmqdUnTl1m0RL8JYefuXB1N63mHBzr48CF3cm6aKXviNcj+htm xhv5qsYh6zJa3Dd+1Gs57tykjFtK7zlspfz20W2ciLu1XYMtYlmdtLuyX5Z038Z2fbi/Lf RzomqIZ7Elei4tuM/yeWYkfioqlA3HkKSHMpb9BkfOJiHCXQmSfOcc3D8yeaLQ== 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 4XdNK81ZNFzgPX for ; Tue, 29 Oct 2024 21:13:32 +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 49TLDWgk055137 for ; Tue, 29 Oct 2024 21:13:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 49TLDW43055136 for bugs@FreeBSD.org; Tue, 29 Oct 2024 21:13:32 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 21:13:32 +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: marklmi26-fbsd@yahoo.com 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 #68 from Mark Millard --- (In reply to Henrich Hartzer from comment #67) Laundry pages are previously active pages that were modified (not a copy of what is sorted on media) and have been prepared for potentially writing out to swap space. (Swap space can be added at any time so being prepared does not require that any Swap space be in a ce use yet.) If they were deleted without being written to swap space, data/information would be lost. Unless the program requests such a deletion, this loss would be a major error. Note that there can be modified pages that are Inactive and have not yet been turned into laundry pages. Memory pressure tends to free pages that were not modified but are Inactive. This is because there is a place to go back to in order to make a copy the original content: the free activity does not destroy the information but makes memory available for other uses. I'll note that memory "pressure" created by one process can cause another process(s) to end up with more laundry or even to have some of its laundry pages paged out to swap space. Having the laundry figure change at the system level does not directly indicate which process(s) had some pages reclassified. Avoid assuming that the process you are using is the one that has its laundry status change when the system figure changes. For all I know, when memory "pressure" decreases, various processes might have their laundry contribution decrease as well (some going back to Inactive?). One thing that does move things out of the laundry category is that page being put to active use again: Back to Active. One process that always stays runnable and keeps enough RAM in active use to prevent meeting the threshold for free RAM is enough to lead to OOM activity. For such a context, that always runnable process might not be one of the processes eventually killed and its pages will not become laundry (or even Inactive). --=20 You are receiving this mail because: You are the assignee for the bug.=