Sulev-Madis Silber <freebsd-current-freebsd-org111_at_ketas.si.pri.ee> wrote on Date: Wed, 23 Apr 2025 06:55:06 UTC : > > On April 23, 2025 8:34:36 AM GMT+03:00, Mark Millard <mark...@yahoo.com> > wrote: > >On Apr 22, 2025, at 21:59, Mark Millard <mark...@yahoo.com> wrote: > > > >> Sulev-Madis Silber <freebsd-current-freebsd-org111_at_ketas.si.pri.ee> > >> wrote on > >> Date: Wed, 23 Apr 2025 04:31:41 UTC : > >> > >> . . . > . . . > > >> > >> > >> If FreeBSD 13.4 can still swapping out process kernel > >> stacks, you may want the likes of /etc/sysctl.conf > >> to have: > >> > >> # > >> # Together this pair avoids swapping out the process kernel stacks. > >> # This avoids processes for interacting with the system from being > >> # hung-up by such. > >> vm.swap_enabled=0 > >> vm.swap_idle_enabled=0 > > would it be related here?
The settings prevent one way of ending up with a normal way to interact with the system failing to do so. There are other means of having such failures. The settings should not lead to problems of themselves, even if the conditions they would avoid never occur for other reasons: The settings should be safe. > >> > >> (I've no clue that that is why you lost control but > >> it may be a possibility.) > >> > >> (main [FreeBSD 15] no longer does such swapping out of any > >> process kernel stacks and the 2 settings have been removed.) > > > >Are you using a file system based SWAP space? Vs. a > >Partition or Slice based SWAP space? > > just 2 gpt partitions Good. Are they encrypted (GELI)? Having the SWAP I/O also involve such processing by FreeBSD does add to the risk of memory management related deadlocks, as I understand anyway. Can testing without the use of GELI to see if that makes a difference be done (if GELI is in use for the SWAP space)? > > > >Quoting: > > > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048#c7 > > > >on why it should be Partition/Slice based: > > > >QUOTE > >On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com> > >wrote > >on the freebsd-arm list: > > > >. . . > > > >swapfile write requires the write request to come through the filesystem > >write path, which might require the filesystem to allocate more memory > >and read some data. E.g. it is known that any ZFS write request > >allocates memory, and that write request on large UFS file might require > >allocating and reading an indirect block buffer to find the block number > >of the written block, if the indirect block was not yet read. > > > >As result, swapfile swapping is more prone to the trivial and unavoidable > >deadlocks where the pagedaemon thread, which produces free memory, needs > >more free memory to make a progress. Swap write on the raw partition over > >simple partitioning scheme directly over HBA are usually safe, while e.g. > >zfs over geli over umass is the worst construction. > >END QUOTE > > > >Note the references to ZFS and GELI. Your forum notes reference such. > > > > > >A separate tunable: in case "was killed: failed to reclaim memory" > >is involved but not reported/recorded: in /boot/loader.conf > > > ># > ># Delay when persistent low free RAM leads to > ># Out Of Memory killing of processes: > >vm.pageout_oom_seq=120 > > helpful here? This tunable contributes to how long before one type of OOM activity starts. Larger values lead to larger times. The default is 12. More than 120 can be used. The figure is good for allowing known temporary conditions time to complete so that they do not lead to OOM activity. It used to be that FreeBSD reported "out of swap" inaccurately for some other conditions where it now produces more accurate/specific messages. There is still a "out of swap" catchall that can be inaccurate. The setting should not lead to problems of itself. > > > > > > > > >Separate question: why did some forum top runs show > >qemu-system-arm threads? That could be a significant > >competition for RAM+SWAP. > > it's small vm yes. but it behaves well. part of it gets swapped out. then > back in, so on Just because something appears to behave well considered in isolation, does not classify if it is contributing to system level problems. In a small RAM context, top showed 600+ MiBytes of resident (probably active?) memory for qemu-system-arm, if I remember right. In other words, possibly 600+ MiBytes not normally available to to other activities that compete for RAM, at elast for a time. > it's all funny, i might be using more things in that machine than i have ram > for. but it just gets swapped out. swapping it back in causes delay in that > thing that needs that. like always It also leads to delays in whatever had pages written out to make room for what was to be paged in, time on overhead instead of on more-directly productive work. > i still think git does something here. I've no way to collect evidence relative to such issues. As stands, I've no way to use these sorts of notes: I cannot even produce a setup known to be analogous and then test it for if I end up with the problem reproduced. (Apparently, that context would include use of qemu-system-arm in order to be analogous.) Your context may be too complicated to reasonably set up something analogous. > if i don't touch git, everything is absolutely perfect. why git? if i > restrain it from config, it seems to not cause issues. except maybe they are > hidden now > > whatever happens, it happens in memory that is impossible to swap out or is > not preferred to swap out > > git is not swapping and then being killed. that's not how it will affect the > system. i think i helps zfs to take all memory and either throw unusual > errors, like that single case. or just cause total exhaustion > > what's fun is it never appears elsewhere. everything else seems to work as > one would expect it to work when low rammed I've no idea how to put that description to any use or to test confirm or deny any of the hypotheses involved. > > > > > >=== > >Mark Millard > >marklmi at yahoo.com > > > > > > p.s: > > i also found > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231457 > > where people experince (maybe) similar issues many years ago > > is it active issue still? FreeBSD 11.* was a fair time ago and various issues have been addressed since then. It is not clear how that bugzilla could be of use. === Mark Millard marklmi at yahoo.com
