From nobody Mon Jan 15 11:15:45 2024 X-Original-To: freebsd-current@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 4TD8hf1WKlz56gZS for ; Mon, 15 Jan 2024 11:16:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TD8hf0HPcz4Fpk for ; Mon, 15 Jan 2024 11:16:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705317360; bh=cfCMy5VdtuMsk4Tjng6TEwC9YzmuIKz8ZOO7odpXUo4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=h/p4DpqkOdNoepMBQQpUF96G1NHvJRhmhQVh8GyuqS2ncUoNLsRMiTW95uIj7qk9rmU/9XkjpaE7zYT4ynqrXKb9DUJUll+EaX+xmpl+pERtHeOzsSvKlEucBWa1No9YeeQkaog2E24HlVloy4Yvr0zF/lTdwAnYVHz+i2AFiuBNgatOtdUHx/qYKe2VHUgjOc6b5qxLh4VQBs6Y6F+MDHzi1pwdDEd/3niTghSjrn/0Cpa3aCTKbw0+6U2w3ntS5wY4ndf/T5kzJKh8rVtU/KqLIqm1v9fw66+oGpPhF7tg4mjt1wpp4yL6s2BB86jeZvM566tYqlVbgHX0cN9M3A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705317360; bh=KG98Fx/UI8AnvRaTArIv39BOoPJKhC6HiAF3nuiMCbT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y4bBsBA+QUMo8ifZr6h4ilr44YzABBf/G7Ou/dYqt8freIz288yi7y2KogcEgKBOncchil2tEIOuoansGjt0tmXIBKIvK5WYfn8AMO2uG4+8I1hvojQ4Zhgc8IHDYe0VpmEwALd5DPVn1vQDfZWy7mtYeSoOSCUntLokn5EjJynwPVc4OVMNY32u3xH4Iuyrdq3DqJ7x6BbkJlTPoX8g6GeO9Xv/JT5/SkOHs5pNuh68AUlm5ZOX56OrWBx20dZeoKdLHUBwKFALKPMpllKSpRwOmByzDbYnUdXxMvUNSbNfDY/gzsJKH5yGgzEfUAJgXdZIgHLHImpNFmgQ57RWRA== X-YMail-OSG: IETmSFEVM1khFMtG.pB1NT7wL.E0f7XiGWAQ2QnyrVWM.Oy5k5zRcT7P_uCclxG SQfCme3zV4I2eFitYPCE7IVF504nPyZy.G72nJvYqSVkkx7w2iJp.VhWbyqFmVqwSLKvZloxQvHD FRUO7vh4wjVsD6KTVURpOVCYcchTbztcwfUsGFtdDlrvT27cefN8N5qjAC2F.enWBS6xC4YZ6T.o mLH347DVkKByYCGGfVX_rWXtuKcLExh8gUiVuafPhDqesmBBze4FikAlKqdfgVlqEGoi6dlX7cQw kvQHOfeytdhlcDygj55sAna5Q6rggPcjCxiAR4Uv2.hXKJlujgh6O5b80M_b85UHbKj07hV39bsI or8vGJgSM2HAkW7KMkoK2o7kRahiIVVZAxxvsgZHfKHWVo6hz72urLSSFTfqUA6ehr_G2jWn4JdS xKsrN1b4Wv_oQylUwcTMhAjBlJHrFNxCne.1k7Jsvw6tecfuvNwgW.bs33GLa4EwNC8HgBIaANiC ssLAz2NJkH12IvO9DjKdqzyC2sjcoPoRmgHlpung9_Wr4tZYjaR0CfeOKB23KsA3CE4baYeakrYx KZpsakLJyBzZo0CIwAHWbqCAnk28LSu5yQN7raF6krTen1ZZD3HUNfGJnMPIFcDKSm0DnwksXBKz qqRjm7uJqzmGA.i.fk5U8oi1b18rJuITxDeXiTVwnQny4g9_RJILlkU45Z1ddzSV1i7Cncbl64mi paM9XoUGbwHT5RV30WPwTQ1dwXBuym.BiONcVoUPWvVTT7fWkib2SqiNvU8Li6F.hRahd_OAj793 baYI_k_rkg6pLEOXQK9rxTXaywlkUxh9PxRhjS_6FVhj7CD3i4pRk85TP72rMyKBtM1VH4OJU_Uc JXwwklK3wULPGznRXDzDxbKx2L_ycFygDFQlSeOIB4DFNioTnvC8hUhYB471z66DfcohlQgmSIoy e4iVUeO7pXqj5t6Ssa_kWkgb7MZA0pOSTNtFsW.qSgy7D4bjgASzDgXdHYkc1gloYZkh0tl4htQR GCA97HDhbY0xUpcdUm6IfZYqzcU7tD4DFLNjMlsBdnUS8I7lrZOnw4DgoNMb6ywU0oIVKjDmS1.7 izFJ9Sjgtx5SSHmYAYJLHKA8KhI1qZ1Hn2wT1oEEjntA5STa3BtGFOFzpv_PORKDFwT.N.JjEVzT 2QcAcn5KclJ8lSqEqYl.kAU14CjpabUZqNy21GZmP8vWraT16bphktYViAkkV2fcHUfr69WkYyL0 F2S9IAdOeQOtknwRjnwNeXiZhFNjtJVnuoBtoD1ahjsuNYoW9fx6ZxpXsx18QKMg3NuLcX_7Ww3K AJ.gW1PvK_ytcOkQdCiv8d8nvisz0XjfAiGsCRF9VOEDe.SvuwtV9g2BcWKGpmOfi1klt3j.u83A zQ5kVyZBL_8HV_0TFu1NGBCP9b17M77YNUqJQ1OlX.SzqbGYxbs5OeRi7uPyDYCEjjgSQ6NSdHP2 TMeThRnqPzWYgMxHOePWmZ9aFoZ9ncsoF5IAADQOX4okvoRIpwBkWKsvpPiMIGdc3JVhupk48uuS nmpqhEzoBtsl18NE2fU7JrtJRZ_EUF_WP3Ag5_YzoDySyJRwEPhfUjFlsaOp_UCxGaT4bRu11oE9 e.cYSszUSDAEIPIXo170XfQ5AJMA1p716pwdEetxkqFspEGSW4UzhG2VqA2_8Py1.bpGODmw2F6E VEmGbWUoZqrPTka0tF_nFRc8L22h9S5jxxmQOOmXXv4xCgEXKzA9spnLG98nEKHVBTni_AQs8Nnw kU6tDjcF9FWPECY_zEvxznc9UJsVGP3ZFJ1S.JW0mKvKMlhkHoPe58INb3X72Qlf.CPeK1kmW7XR xeNIflDDeuGy6ud69SDrhnPedeHr9oz6F74NbYNf5ClNegGoQ943r7U1zCblXaXpMfhX1XMEyzfD L9cdH2GmX1oRJN8qyhCXuP6I_XfU3S_12RDjDjWL.JPaQbOZ3yOiGfpe9TN_7_uDOFc7XtXiB.8f eJVZ26_WuC.0y4QfEOvVigJ_JjUfJKSpH2k4k813NN41xeEbm.j00hqx0fNBkahURFX8gy0i3oKB 1GB0g1nrc1T4Pb_U4jn4mru325x0jB0Yqo3JhX3gtk1kZHz6DLAfwcx7cgM_gkdOBCh5BpOkoolt WwWkew913P5xzNHJ6YLcEHmu0WLP3QEy7twVg3.hvXXxZ4vDQhONLuJ0RqYFBiMe...gwkkM6Mu3 GVDdJHNK3COF1YBc9uz06d.SbelkWnDe0lnCQvnA_HobfPpvQ5c8TOt60Qn5m_XmYVEiG_pvQ6uc FrzY- X-Sonic-MF: X-Sonic-ID: a384cd18-c956-49b3-9698-6686b5c88c25 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Jan 2024 11:16:00 +0000 Received: by hermes--production-gq1-78d49cd6df-wz9pk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 49575d90d026312df23127e85efc35ae; Mon, 15 Jan 2024 11:15:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: poudriere: swap_pager: out of swap space From: Mark Millard In-Reply-To: Date: Mon, 15 Jan 2024 03:15:45 -0800 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5.ref@yahoo.com> <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5@yahoo.com> To: Lexi Winter X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TD8hf0HPcz4Fpk 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:36647, ipnet:98.137.64.0/20, country:US] On Jan 15, 2024, at 00:07, Lexi Winter wrote: > Mark Millard: >> You seem to be under the impression that "Inact" means "page is not >> dirty" and so can be freed without being written out to the swap >> space. >=20 > indeed, i was, because this is how sysutils/htop displays memory = usage: >=20 > top(1) >=20 > Mem: 8502M Active, 15G Inact, 1568M Laundry, 5518M Wired, 1343M Buf, = 690M Free >=20 > htop(1): >=20 > Mem[|||||||||||||||||||||||||||||||||||||||||| = 13.7G/31.9G] >=20 > i'm vaguely annoyed, but also not surprised, to find out that htop is > wrong here... htop is not native to FreeBSD, unlike top. So making it fit is odd because Inact can be a mix of dirty and clean pages. >> Inact pages can be dirty and such pages can not be freed without >> being written out to the swap space first. If the swap space >> ends up filled, dirty pages that are not in active use stay or >> propogate into the Inact or Laundry states, accumulating there >> (for later potential use). >=20 > so, how are Inact pages created? They are just non-wired pages that have not been accessed in a sufficiently recent time, no matter if dirty vs. if clean. (Wired pages are never written to swap space while they are wired.) Buf pages (as top shows) are clean but can be active or inactive: it is not an independent category. But it counts only pages used for buffers/caches. There could be other clean pages not counted. FreeBSD does not page out active pages. Thus, a program that keeps all of the non-wired RAM Active will not page out to the swap space and can lead to OOM kills. There is a parameter that indirectly controls the time before such OOM kills happen: vm.pageout_oom_seq that has a default value of 12. Larger figures increase the time it takes for such OOM kills to happen. I use 120 to avoid OOM kills in my range of contexts: delays long enough for things to complete in my contexts. (I reference time to simplify the details.) > does this happen from filesystem > writes, or something else? All non-wired memory is subject to potentially being Inactive. It is not limited to file system memory at all. > is there somewhere this that is documented? Inactive pages that are not dirty are freed based on memory pressure. Inactive pages that are dirty can not be freed without loss of information. Inactive can be an arbitrary mix of dirty and clean pages. Only dirty pages are potentially moved to Laundry. I have seen wording indicating that all dirty pages are in the laundry --mixed in the same text that such pages are first inactive. The observed behavior is that the/some dirty pages that have not been accessed in a sufficiently recent time go inactive first and later can move to the Laundry --and the pages that are written to the swap space did make it into the Laundry first. One place to read a description is: https://klarasystems.com/articles/exploring-swap-on-freebsd/ Part of its text is: QUOTE The active and inactive queues contain both clean and dirty pages. When = reclaiming memory to alleviate a shortage, the page daemon will free = clean pages from the head of the inactive queue. Dirty pages must first = be cleaned by paging them out to swap or a file system. This is a lot of = work, so the page daemon moves them to the laundry queue for deferred = processing. The laundry queue is managed by a dedicated thread, the = laundry thread, which is responsible for deciding when and how much to = page out. END QUOTE There is a description of top's output as well: https://klarasystems.com/articles/explaining-top1-on-freebsd/ but it is not clear about the dirty vs. clean status of Inact vs. Laundry, where Laundry need not cover all dirty pages. Nor is it clear about Buf counting a mix of Active and Inactive pages in its count in general. =3D=3D=3D Mark Millard marklmi at yahoo.com