Re:_Arm_v7_RPi2_-current_unresponsive _to_debugger_escape_during_buildworld
- In reply to: Mark Millard : "Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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