Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task
- Reply: Mark Millard : "Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task"
- Reply: Peter : "Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task"
- In reply to: Peter : "Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 29 Feb 2024 17:40:39 UTC
On Feb 29, 2024, at 08:21, Peter <pmc@citylink.dinoex.sub.org> wrote:
> On Thu, Feb 29, 2024 at 08:02:42AM -0800, Mark Millard wrote:
> ! Peter 'PMc' Much <pmc_at_citylink.dinoex.sub.org>wrote on
> ! Date: Thu, 29 Feb 2024 13:40:05 UTC :
> !
> ! > There is an updated patch in the PR 275594 (5 pieces), that works for
> ! > 13.3; I have it installed, and only with that I am able to build gcc12
> ! > - otherwise the system would just OOM-crash (vm.pageout_oom_seq=5120
> ! > does not help with this).
> !
> ! The kernel has multiple, distinct OOM messages. Which type are you
> ! seeing? :
> !
> ! "a thread waited too long to allocate a page"
>
> That one.
That explains why vm.pageout_oom_seq=5120 did not make a
notable difference in the time frame.
If you cause a verbose boot the code:
if (bootverbose)
printf(
"proc %d (%s) failed to alloc page on fault, starting OOM\n",
curproc->p_pid, curproc->p_comm);
likely will report what process had failed to get a
page in a timely manor.
There also is control over the criteria for this but is
is more complicated. In /boot/loader.conf (I'm using
defaults):
#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
#vm.pfault_oom_attempts=-1
#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes (showing defaults at the time):
#vm.pfault_oom_attempts= 3
#vm.pfault_oom_wait= 10
# (The multiplication is the total but there
# are other potential tradoffs in the factors
# multiplied, even for nearly the same total.)
If you can be sure of not running out of swap/paging
space, you might try vm.pfault_oom_attempts=-1 .
If you do run out of swap/paging space, it would
deadlock, as I understand. So, if you can tolerate
that the -1 might be an option even if you do run
out of swap/paging space.
I do not have specific suggestions for alternatives
to 3 and 10. It would be exploratory for me if I had
to try such.
For reference:
# sysctl -Td vm.pfault_oom_attempts vm.pfault_oom_wait
vm.pfault_oom_attempts: Number of page allocation attempts in page fault handler before it triggers OOM handling
vm.pfault_oom_wait: Number of seconds to wait for free pages before retrying the page fault handler
===
Mark Millard
marklmi at yahoo.com