Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Feb 2024 10:18:28 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Peter <pmc@citylink.dinoex.sub.org>
Cc:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, "Edward Sanford Sutton, III" <mirror176@hotmail.com>
Subject:   Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task
Message-ID:  <79745A1B-0061-40FB-89C3-E71893D0D18D@yahoo.com>
In-Reply-To: <F0025F52-4E6E-4C7B-94F3-126E2BCEAF7C@yahoo.com>
References:  <426089C7-A15C-4B04-BC47-D1F77089C492.ref@yahoo.com> <426089C7-A15C-4B04-BC47-D1F77089C492@yahoo.com> <ZeCvASiCcwEYBxH6@disp.intra.daemon.contact> <F0025F52-4E6E-4C7B-94F3-126E2BCEAF7C@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 29, 2024, at 09:40, Mark Millard <marklmi@yahoo.com> wrote:

> On Feb 29, 2024, at 08:21, Peter <pmc@citylink.dinoex.sub.org> wrote:
>=20
>> 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 :
>> !=20
>> ! > 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=3D5120
>> ! > does not help with this).
>> !=20
>> ! The kernel has multiple, distinct OOM messages. Which type are you
>> ! seeing? :
>> !=20
>> ! "a thread waited too long to allocate a page"
>>=20
>> That one.
>=20
> That explains why vm.pageout_oom_seq=3D5120 did not make a
> notable difference in the time frame.
>=20
> If you cause a verbose boot the code:
>=20
>       if (bootverbose)
>               printf(
>           "proc %d (%s) failed to alloc page on fault, starting =
OOM\n",
>                   curproc->p_pid, curproc->p_comm);
>=20
> likely will report what process had failed to get a
> page in a timely manor.
>=20
> There also is control over the criteria for this but is
> is more complicated. In /boot/loader.conf (I'm using
> defaults):
>=20
> #
> # 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=3D-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=3D 3
> #vm.pfault_oom_wait=3D 10
> # (The multiplication is the total but there
> # are other potential tradoffs in the factors
> # multiplied, even for nearly the same total.)
>=20
> If you can be sure of not running out of swap/paging
> space, you might try vm.pfault_oom_attempts=3D-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.
>=20
> I do not have specific suggestions for alternatives
> to 3 and 10. It would be exploratory for me if I had
> to try such.
>=20
> For reference:
>=20
> # 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


I'll note that vm.pageout_oom_seq , vm.pfault_oom_attempts , and
vm.pfault_oom_wait are all live writable, not just boot-time
tunables. In other words, all show a line of output in:

# sysctl -Wd vm.pageout_oom_seq vm.pfault_oom_attempts =
vm.pfault_oom_wait
vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM
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

Not just in:

# sysctl -Td vm.pageout_oom_seq vm.pfault_oom_attempts =
vm.pfault_oom_wait
vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM
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

(To see values, to not use the "d".)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79745A1B-0061-40FB-89C3-E71893D0D18D>