Date: Mon, 15 Jan 2024 03:15:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: Lexi Winter <lexi@le-fay.org> Cc: Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: poudriere: swap_pager: out of swap space Message-ID: <D4DB864A-6702-4048-BF8C-B9C8814C73FA@yahoo.com> In-Reply-To: <ZaTnySBEUrrzoxNt@ilythia.eden.le-fay.org> References: <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5.ref@yahoo.com> <60C36CF0-43AC-4ACA-B6A5-6997F4425EC5@yahoo.com> <ZaTnySBEUrrzoxNt@ilythia.eden.le-fay.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 15, 2024, at 00:07, Lexi Winter <lexi@le-fay.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D4DB864A-6702-4048-BF8C-B9C8814C73FA>