Date: Fri, 23 Jul 2021 19:04:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257314] FBSD 13 crash after some KDE parts crash supposing out of swap space Message-ID: <bug-257314-227-OWr3yBds3Q@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-257314-227@https.bugs.freebsd.org/bugzilla/> References: <bug-257314-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257314 --- Comment #16 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Mark Millard from comment #14) The large I/O times may well be mostly wait-time in a queue with a large queue built up of pending I/Os. So: the system generating pages to write after than the I/O system is writing them might be what is going on. (An large accumulated set of pending reads may not be so likely to be generated. That is why I picked on writing out pages as an example.) Again, I'm not sure the long I/O times are driving things. I also made a silly assumption and there is another experiment: increasing vm.pageout_oom_seq. I know someone used something like: vm.pageout_oom_seq=3D4000 I've no clue if there is a figure large enough to have numeric overflows involved or other issues. But this figure likely can be rather large. The 120 value was enough to allow -j4 buildworld buildkernel to complete on low end armv7 and aarch64 hardware. Mixed with vm.pfault_oom_attempts=3D-1 it was enough for someone using a microsd card as I remember. (My I/O context was better for the purpose in such a context.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257314-227-OWr3yBds3Q>