From nobody Thu Feb 29 18:56:10 2024 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tm0sY25bDz5Cjsc for ; Thu, 29 Feb 2024 19:00:17 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tm0sX4nYFz4Svb for ; Thu, 29 Feb 2024 19:00:16 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 41TJ05pf095031 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 29 Feb 2024 20:00:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1709233208; cv=none; b=KsXwp8iksU8L4fbWe45lZke70fe1pRUJmDLM2isoN+IKt4Ko5QbEFdRM3Hs2jLpCeY3OBFtwSDvfb236aocSpQib82drcE/Kb8E4mHoeEotsc5Gobbkf8nbF9jrEn7uhq9YCq+Qlji+jkKjrGn1ZkCegdyjPcIVcsHcxeMvx8P4= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1709233208; c=relaxed/simple; bh=gIlLGLreNtVVenpmmR58Vowu1nQDVej0e77DSTRO0DU=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=HdnHjk1Z9kDVy6WRvpDZ1iVGzi4EwOAp4UVvrl0uNcd5kcrxYGTfXbl5BH8yOJVX0ps6EzCGt3YRuZqUpfMZy4TyJ3rEKafWYJPbPnfTPo1gZPeYxeZ8EJvrsGYtHTcmRA2mCheTS0YTHGWq1nKee4LVXcDK71/3euemaLqcr6U= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 41TJ05Gj095030; Thu, 29 Feb 2024 20:00:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 41TIv6CB071627 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Thu, 29 Feb 2024 19:57:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 41TIuAdO097704 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 29 Feb 2024 19:56:12 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 41TIuAZ6097703; Thu, 29 Feb 2024 19:56:10 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Thu, 29 Feb 2024 19:56:10 +0100 From: Peter To: Mark Millard Cc: FreeBSD-STABLE Mailing List , "Edward Sanford Sutton, III" Subject: Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task Message-ID: References: <426089C7-A15C-4B04-BC47-D1F77089C492.ref@yahoo.com> <426089C7-A15C-4B04-BC47-D1F77089C492@yahoo.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Thu, 29 Feb 2024 20:00:08 +0100 (CET) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE] X-Rspamd-Queue-Id: 4Tm0sX4nYFz4Svb First off: the honorable Sir Edward, III. had the decency to have me ntified that they prefer to censor my messages (reasons were not given), I for my part consider it rather pointless to publicly ask questions, only to then inform those who bother to answer that one declines to receive their answers. So much for that. Now for the call for popcorn: On Thu, Feb 29, 2024 at 09:40:39AM -0800, Mark Millard wrote: ! > ! 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. Good. Glad it explains something. ! 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. These are ad-hoc bhyve which are only created for the purpose of compiling some ports. So there is zero interest about /which/ process fails, because any failing process will just fail the build. The essential point it rather: the very same sizing of ressources works when booting a 13.2, and crashes reproducible with 13.3 ! # run out), avoid pageout delays leading to ! # Out Of Memory killing of processes: ! #vm.pfault_oom_attempts=-1 Yes, I already got that far, and that doesn't help: If the system is neither allowed to oom-kill nor to crash, it freezes and waits for the reset button. As this is an endless loop in the kernel, it is not ressource exhaustion, but rather unability of the kernel to adjust ressources accordingly due to being busy with other things (i.e. running an endless loop). But then, discussion about this is futile, because there exists a patch that well expects and nicely fixes mentioned behaviour.