From nobody Thu Feb 29 18:18:28 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 4Tlzxk3jvqz5CfT7 for ; Thu, 29 Feb 2024 18:18:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tlzxj2JrTz4Ls4 for ; Thu, 29 Feb 2024 18:18:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fLWRLuc6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709230723; bh=VPuRNGepIq4tVClUGqwJTeptgGcvrmVIG6OcFfdewsI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fLWRLuc6N9y9WVvzPvGJ4zjV576gHk0mGoCOLV4yM4S8jlyurKpfJQXMAKEJfNWYKbhPWmiNRRQ/H8rtkQOSR/+1mDm4qrd0uSjk0eSfT5C5YpuAQZ9p4GsV/XDgTBXpl2d10tMSxhxoOEkKupUA3vYX2uddl8KpLqy7aTzfd0Jbe8z5+LARuXAepa+BMPkgd8b4hm8DnTtat6Cw5KQrjWkkQrGj5/ho3Dez+dBv8JBdVpWXVoB1fO+FY0PLv8hJ2PWLyepBu17KDXdI6RQtfISDwaGPwBpLKfq986a+omgNTuD/8IfFTIZ6eJrEzxFEn6/dO+JnSgRN2ANXQtBsNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709230723; bh=Xyx7vWLdtUUzCTXsDqwopM6GAHpZv/9tqihGo2z3rF4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Nu9V2ieA7L1s5RTCcnBHVSvgPYh5bQR09IAXB8PPamkkXO1rVVgpFqaG0Pjcd8jUV7U84Oou1HmBnAlxJsGPXicI2SE45gOuw3jsMQ558XZ3H8ecnFdLJ7lsse7/8KOK0KY+6gPtbkGkgoDj05241hyIO90k896O+9sJuPrzWSE60dkGbjmMyFAQck8VmvdU8K7X/xcW4wwCe2FcrEM9UaVzdKwjpLPiBNpJ8w+EdcSVIfUQTpkloz4kFEr/TMvabZcn4Fc/aIqe9GuXqUcLDnwBr4YS+MhScR7axJK31vl5l8egn8bhyhGo6vKSHSSlzkjJZBymIHv1RdGvp3M62Q== X-YMail-OSG: j7SlnusVM1lOfNBAIYpnByq.irZHGfrmGvQZV.iL1PFNm6ALy824RNYC8XIFIJ3 hL4DsjhICO1Uko7KYDAtVVFObYE9eVSIU6sD.Dn6BuggkhROma63NgSJ9Zy0i926nW3qMzdrEGua 0ybef0v70drNP.id68NDuOd7SPF24dZ_yEXss3I9M6AAaRmcAjTwiBP.15Hz_5LEQEKQsYOpYnr2 n9z9tTpA6wHmt5EiYyGn_sa74s3N.Jm8fM6pTUMsO1wq0j8JnWCK9vPsl7z62TWSUheX7hWsFmcR VOb8eHY5ZokXhHrjBpbloUnPF3OW0oYKujbkKW1iUEUdVbSdjX.IIqdUl166oMy5ylDUZtJbrhoA knYmXbDDg.cKehaGxRFeinLQSuLYHGpW0a4SX.0pRfrR5wP4hcdOm4bsmBxroszu6yM6_e4Ozmkm 6vPvfsMTNQM5XPG.83TwBO1e4XvjJR.sGD6OXZRO_UYnh9DZhCAUNLKxr8NT.AP4f0iJTBXDmp0W aOaImxrMNoVl_1C9Hd..tBZJbkEdZ_II9T6EGLEpgvJrIfuhIWjYKBvN9ge6xLdNF0j2Hz7N8VbQ FnwsS5T7wyPRIPPeuptut1OUO8Clp7MMPMpbYT4UP6pyrVZswTZJA9FtptO7R3AJRml.4sU5UeCe PwjJclOpIg_ZOJtu3TRr1kxbZ67QpKtEAKWhsh4ZAO6n2iEAfGquwdTLmQykkYz2kDXSTnhiHqNu _C0jJacQlfVZqmA3xTa7hUJ4TBe4Myim3OGsQmGSpn_xZh_G9qUcDQqWS4USgXM50a7DXLMARTX5 UIfR.ZIGlG5MmVyXkZeVdhx0z.sMmInePhktQwYxpQ1dj9z5oqy62axKfcME3w7WCW5CBxnt60zo Gy.DnLxS0fA4_9QtJ8Mm85fMn.rS_wJIsY166XtoZAMGaYasLQKZzxAvMyI3w_GgYV7MVh.gc_VB lMUNu5lREqtOkFQk8aSZ5qJSviS6PZvXboCw7jPgSCCkhB414lWjZEis3hnOgmqBwCT9ZCamI19G 8awB6pqzSwf8JaSKamtwgTfPskaJxWo6jblafz2j1DUtIypQ0hX4sEqHe5N.Hol2BN0XvZS5.fOX THuiz73r5kvZFSmkftCmTbApL59oIhH3CNIH696COR1CjDWxi3.dQ.Ymkn1M4YwRgaMo84y6Sj_A 5hJMfiYoBwNyeBcv0aiXDRFcNLqYBrfRWJV9xQR9XBUA0kVlDlIKs0gRqmsRQnv2Bw1Fiz87LpNo 5mF9OVv8O2qY_ZAxMW27lh1Z9Zku0kgXnEzOR6dtavadyO38HyPawgUZxsIzC38KmBsQSfT6RV1K 0BPRsRIFMY50_XSw_iW0PEoTBeHoMJRBv_kstk7WKz.uPIPFntVkflMCMXO1_CnlLGjn4hZi9buk yuGkdBMrw01_H3RA6EJRqgZd6CxwgzR0nxmsUZTO3Mz6iGWL0Fk725iOab6M7gR_rx4Zi.ugJRL. tzM2ba71x2vnLxCSUB2Klpgp_9tLjOeytJ4K7rRFReG96DGNcDbrbyrYWCaHcJId5s9Ji97eBrJw t.EbX14W5MzSiC0.x8rZB6N_.jpwtcx7frKbjsePZPkMTBrw4qrVcwpH_oYCRT4HgUMxEKJGnaLV ofuA3kDJQyAkmyJGi9ZT1e.tJw5oKXAycTdxQtbiysTYibsJUxaTGib3h2a0L4Ok1DB5cEMOKM.6 9QJtGU8cx1FMVhwmAfpHK9Bq4MxiqFB2PXigTucq9MxmE7jySAvvM9xlt9VlFKOqmfQ5rZN73._I TToiKClS7XQnGVsIkR1KRY1dxnZhnmI94fJqTXtNNz_7vbaHOeEgdHLdwSJDUGs2wzzVfKDuus41 Tv9g.9rX3XVcczhFqFHq3Ogsg4xvuFqFgLjMJHySXTBN5a81A11AKibyUseMOkBh2SqtNr64hEAO 3xyaYEA.ElkwULDV4DzDrW3GYq1BTba80XFOtK8vGSrfy1N0J.Nu4WcPOUJnH3V3SQYESMLQbcKd 3C5k.v3j51kkVtt1qVEDb2p5qqb26GqklzQTVXFObGz6QmY8NuhsVgJQrv9BWtfxTy1e2RMZjMec Tcmv_hPFRVO8hqCKQ3d3._d0IzxEceYN606u7GxVJ_uIYeUaS.WrHjrVCbOXzJavfURBummuxoZf UpB_FBahOCW4hlkQF2.O0WQAbX.cpyFoqdy.vzRhVUlUULbtUpDCGWcUcF9NrdH.PWpq11roALR7 qLIaYLVGnzl8OaB_lBmVnZXmNKF0PcDUSXG3z0DFkUZOkgLSFKG063c.6LIE_5x6Uxv3KYoiEGMN wEQ-- X-Sonic-MF: X-Sonic-ID: d2a30b31-2869-4527-8437-6d0f46e294e8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Feb 2024 18:18:43 +0000 Received: by hermes--production-gq1-5c57879fdf-hjdnf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a5961f765e20f00975aa8b08edb4cbb7; Thu, 29 Feb 2024 18:18:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: 13-STABLE high idprio load gives poor responsiveness and excessive CPU time per task From: Mark Millard In-Reply-To: Date: Thu, 29 Feb 2024 10:18:28 -0800 Cc: FreeBSD-STABLE Mailing List , "Edward Sanford Sutton, III" Content-Transfer-Encoding: quoted-printable Message-Id: <79745A1B-0061-40FB-89C3-E71893D0D18D@yahoo.com> References: <426089C7-A15C-4B04-BC47-D1F77089C492.ref@yahoo.com> <426089C7-A15C-4B04-BC47-D1F77089C492@yahoo.com> To: Peter X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[freebsd.org,hotmail.com]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from] X-Rspamd-Queue-Id: 4Tlzxj2JrTz4Ls4 On Feb 29, 2024, at 09:40, Mark Millard wrote: > On Feb 29, 2024, at 08:21, Peter wrote: >=20 >> On Thu, Feb 29, 2024 at 08:02:42AM -0800, Mark Millard wrote: >> ! Peter 'PMc' Much 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