From owner-freebsd-current@freebsd.org Sat Nov 24 17:40:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12392110EADC for ; Sat, 24 Nov 2018 17:40:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 778C4843EB for ; Sat, 24 Nov 2018 17:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id 33BCF110EAD8; Sat, 24 Nov 2018 17:40:48 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10EC4110EAD3 for ; Sat, 24 Nov 2018 17:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12BB2843E2 for ; Sat, 24 Nov 2018 17:40:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: DQa7A6YVM1mr4wQ1D4HaFeVGHEPrpKKY.z41KoOmfDKGkWnc8XeHKNRYRgf8g.I EfgqokUPTwdsN1h14U3PVv6csEWMpz1PrvapaUYPmtdh0kr6OBk7RPyWTMmMRU86MSi_2uY1CFDj CR8T61.xnfzJRtJLNAXwAwqL3Ht1rwKTRao787pb1DgeqZWvpI5EEXvWR0_21Uq0CwOXVliFUxXv wIs1DtFWMRGI2uJMQon.G90Wx9FLizIVyWRkakTIv6VVjNrJevu5EPz2ZppxR.kVhwvtEwUd2zw6 7N7L78VWLwjUJ5YEEIxvAccaoXfPho_w4yBHOATCeP6C6hPjAfZmE6lCyFVvcouk886Hw0ZdD.ld Yd9KfVUZLKuKyK2gwulSrZjLO6.rHN3ohoA.JdsPZcn.6z_MndSxz27RiKFVXpw6jUphDILjmbzT VHuOGhd02c9MbW2Y8ldN3S6jt6BEoYQiGEAFzKrTVsWbFasyPWvrmj5wbpkW5_M38umEOrbKbD_F OloVikbGLqyfJbmoV03KaOxST.PigmTy2PLIYDslQgbp.T9ByUgXfIGfj8.KWJY8yIsOrpAvFXTJ _aW6O0lKkciq06pgr3jEEaYzvFrEBEnBmjWu9PSi4mEvdweGmrblGwS8Ykt7SG8UDY4CgO2aTBzu QBV2QaOq2as6VheZIxPIJFYVfWTdlYI7_YyW_Ft_0sS_gQBFarWJYGc9Y9aNcjZeCweF6Q.bt.uK .lIB9A7ZOzmvRGmGpcuP6n9JkU12e9orDDp1DpdoTw6iEwSufOfLdbaQhtP5bRYkeXeXlzrLq8Za MJjzjSXP42uBFTZjg2X7NZc0lTxNKhX2fvVVuTCKwmnodfLoJK7na5CsnS0MRQLpieoDzo2MUmdx tsHo4FBUZwC4EjBetRRsAUskn2SRnPcIU0GnxRcuwgMm8oNJjR3aFpEKG0ZOQS4QV6TvslAKgiQ. EYaiOrYPzd5lghyPuOInwFquFGwQuWe3Pr.UgFmo4Bd9ZmcIQcU2CWbZu5S3XIDe86Zck8RInDZM gNZbGtuhFZ57ouLjDMxpeL583qaOWRT4cZqVlR4Asy1BLx8izjcAlJmL9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 24 Nov 2018 17:40:39 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp410.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 79da480cdadf8d48cb49a10d87a732d3; Sat, 24 Nov 2018 17:40:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: maxswzone NOT used correctly and defaults incorrect? From: Mark Millard In-Reply-To: <20181124104032.GV2378@kib.kiev.ua> Date: Sat, 24 Nov 2018 09:40:34 -0800 Cc: current@FreeBSD.org, freebsd-arm@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: References: <20181124090429.GI10067@funkthat.com> <20181124104032.GV2378@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: 778C4843EB X-Spamd-Result: default: False [-6.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FORGED_RECIPIENTS_FORWARDING(0.00)[]; R_SPF_NEUTRAL(0.00)[?all]; FORWARDED(0.00)[current@mailman.ysv.freebsd.org]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_MED(-0.20)[5.0.0.0.0.5.0.0.0.0.0.0.0.0.0.0.a.6.0.2.4.5.2.2.0.0.9.1.1.0.0.2.list.dnswl.org : 127.0.9.2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:10310, ipnet:2001:1900:2254::/48, country:US]; FORGED_RECIPIENTS(0.00)[current@FreeBSD.org ..,freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-3.66)[ip: (-9.87), ipnet: 2001:1900:2254::/48(-4.73), asn: 10310(-3.60), country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 17:40:49 -0000 On 2018-Nov-24, at 02:40, Konstantin Belousov wrote: > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote: >> . . . > OOM is guided by the pagedaemon progress, not by the swap amount left. It would help if the "was killed: out of swap space" messages did not incorrectly point to being out of swap space as the issue. > If the system cannot meet the pagedaemon targetp by doing > $(sysctl vm.pageout_oom_seq) back-to-back page daemon passes, > it declares OOM condition. E.g. if you have very active process which > keeps a lot of active memory by referencing the pages, and simultenously > a slow or stuck swap device, then you get into this state. > > Just by looking at the top stats, you have a single page in the inactive > queue, which means that pagedaemon desperately frees clean pages and > moves dirty pages into the laundry. Also, you have relatively large > laundry queue, which supports the theory about slow swap. > > You may try to increase vm.pageout_oom_seq to move OOM trigger furhter > after the system is overloaded with swapping. > >> . . . > The swap metadata zones must have all the KVA reserved in advance, > because we cannot wait for AS or memory while we try to free some > memory. At boot, the swap init code allocates KVA starting with the > requested amount. If the allocation fails, it reduces the amount by > 2/3 and retries, until the allocation succeeds. What you see in limits > is the actual amount of KVA that your platform is able to provide for > reserve, so increasing the maxswzone only results in more iterations to > allocate. The documentation's "corresponds to eight times the amount of physical memory" text again seems not helpful unless it happens to be about the figure for the actual context. Could something like your wording above be put in place instead? An example: armv7 rpi2's and aarch64 rpi3's, both with 1GiByte of RAM, get very different figures for the "exceeds maximum recommended amount" figure, different by very roughly a factor of 2 if I remember right, neither near what the documentation suggests. Suggesting a fixed ratio to RAM-size just seems to be wrong. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)