Date: Thu, 29 Feb 2024 08:06:40 -0800 From: Mark Millard <marklmi@yahoo.com> To: Peter <pmc@citylink.dinoex.sub.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Cc: "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: <46C1C5BA-924D-451E-8799-223F1A70413B@yahoo.com> In-Reply-To: <426089C7-A15C-4B04-BC47-D1F77089C492@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[I grabbed locally modify text for one of those messages.]
On Feb 29, 2024, at 08:02, Mark Millard <marklmi@yahoo.com> wrote:
> Peter 'PMc' Much <pmc_at_citylink.dinoex.sub.org>wrote on
> Date: Thu, 29 Feb 2024 13:40:05 UTC :
>
>> On 2024-02-27, Edward Sanford Sutton, III <mirror176@hotmail.com> wrote:
>>> More recently looked and see top showing threads+system processes
>>> shows I have one core getting 100% cpu for kernel{arc_prune} which has
>>> 21.2 hours over a 2 hour 23 minute uptime.
>>
>> Ack.
>>
>>> I started looking to see if
>>> https://www.freebsd.org/security/advisories/FreeBSD-EN-23:18.openzfs.asc
>>> was available as a fix for 13 but it is not (and doesn't quite sound
>>> like it was supposed to apply to this issue). Would a kernel thread time
>>> at 100% cpu for only 1 core explain the system becoming unusually
>>> unresponsive?
>>
>> That depends. This arc_prune issue does usually go alongside with some
>> other kernel thread (vm-whatever) also blocking, so you have two cores
>> busy. How many remain?
>>
>> 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? :
>
> "failed to reclaim memory"
> "a thread waited too long to allocate a page"
Local text:
> "swblk or swpctrie zone exhausted"
Should have been:
"out of swap space"
> "unknown OOM reason %d"
>
> Also, but only for boot verbose:
>
> "proc %d (%s) failed to alloc page on fault, starting OOM\n"
>
>
>
> vm.pageout_oom_seq is specific to delaying just:
> "failed to reclaim memory"
>
===
Mark Millard
marklmi at yahoo.com
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46C1C5BA-924D-451E-8799-223F1A70413B>