Re:_Arm_v7_RPi2_-current_unresponsive _to_debugger_escape_during_buildworld

From: Sulev-Madis Silber <freebsd-current-freebsd-org111_at_ketas.si.pri.ee>
Date: Fri, 07 Nov 2025 18:44:28 UTC
i like to report that i also have a low mem machine, 4g

and i recently just gave up on jobs. so i set ports, poudriere and buildworlds and whatevers just to 1

i have more i want to run in that machine and this is just exhausting all the ram. there's also zfs which seems to mysteriously fail here if multiple jobs happen

tmpfs is also never used

so idea to run 2* cores/threads doesn't always help. sure, if it's pure cpu bound it helps. but if things start to allocate memory, in parallel, it sucks. at worst it fails, at best it just keeps moving pages to disk and back. resulting activity causes every benefit to become lost, it could even get worse

also, if you overload the cpus, where do the other tasks go? machine still has to perform supporting tasks, read and write files, etc. it isn't just compiling

so in low power machines, not all those options make sense. in 3 figure gigabyte ram machines, yes. machines can do >1t now too. there it matters

unfortunately i also made smaller builds slower as there is no way to dynamically adjust jobs depending how much it speeds up or slows down. eg ram use

maybe there could be dynamic option here. if system detects that build jobs are likely to completely crap out the machine, it could just tune them down. this also matters in some of those superservers. if thing is small, it buils hyperfast, if big, it builds fast or normal

i have no idea how to implement that. i just have idea