From owner-freebsd-hackers@freebsd.org Sun Nov 18 17:51:32 2018 Return-Path: Delivered-To: freebsd-hackers@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 D5FF11108863 for ; Sun, 18 Nov 2018 17:51:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 5DB098694E for ; Sun, 18 Nov 2018 17:51:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: bqApfoYVM1lNU9DQXysJjeiYPCvRvPlP5NhocyIIMoBpCXCp3EgtyQKAg15Eq3e duX9jZIw60tWMQdR9CAvS6sk43bD9pPX5I05KcjV6O21wRK6RxGjYg_4R8blCxXbKcunoF5L9ZYR HR9mpe0pyYGmT6RwQf4ojsthaFjUyMEwwDDArtAc.zvlibsCBMZC7OaWr_v.ZBlE9jYf9k30b_hj EHa0HiWdSN_qQTB1_uNqGh5GS6TeA3JfAy0rmy4fzGVWjFPu0W.I5kxqvbPLakIbYDfnQEXF6MQw emOMZI6y99_T8TvWeJK0ICoeJ3VOXV0UWwGoyhyo1gAKbm4VaZjeAG0cAq9.qH91X5E9rujZ7H59 UmtINxSK_A8eTG6Fr3fk4zGcKCwozYtAPtLoDdlAlAVOgipeKzuED1x.9ZvrXcWUw4.ZGFJ3B_Q_ 4RPLSgoZVi7zBRrn._fcB_HtcpdYqos3DpVBUpHXg2OomzztmRF61b.Kpa1lk77Eruy7GtOdNjdu p8y2.yMMexOMLp0Avu5Q7zSWC5qBEc1W_e60r44JUCu5C7k7wnkpiDkQ9hEHS8d.ibt.2cuxhXZl 10GFNNWDDizJMuJS6zT1Y.pNVWoud_HBku1bS3N5A20_NSozKzKGkK_7ZJqSv_ZpmnAQKDJcvmLU Hodlz8LFkPz2hR9jzA.3xu6Uzo1Ke9XisFPDdw_vS4a7e.TEk632YIWC83YPsWFDYwLqDy60Hv5l CxMglIeIzYCOfAi6Wn8XksCQ7w4LZJ_DwhFWbw9lQuRT3X60PHi9xtrSqf9r2thvLsgUUS0YuFx8 u6ThPefzMOi.MqF6M7fjJLNaOyPY6znjQcBkPEyTZiCZg0ujrqc2mKmyQ1NCdftfulJS4b0XAK_. D2Tu_qRhKdzBKmyIoAdB.Uu_x226_rbeM0dEZ8iPxPIXDCBfpw1vH1.fzlSE7zzczUGQRKVZ3rzb w2UdE2PkKcdiJVprHoEvxPnrxSSqIps6ifDcYZ_MpZ0NObuXpriG_NV_CZnA_q371RI4gBUs5x9Y 9NGmgEyEVqgVZ4oAGJQL2iuhw1loLWWYc3zj2zp2BMt9CE_DmPwEhYN7jpNqX Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Nov 2018 17:51:30 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 11f13a1d842a98d891153e8e8bd0a5e0; Sun, 18 Nov 2018 17:51:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: 13-CURRENT: several GB swap being used despite plenty of free RAM From: Mark Millard In-Reply-To: Date: Sun, 18 Nov 2018 09:51:25 -0800 Cc: Cy Schubert , Rebecca Cran , freebsd-hackers Hackers , Mark Johnston , Ian Lepore , Wojciech Puchar Content-Transfer-Encoding: 7bit Message-Id: References: <201811180154.wAI1smhg049214@slippy.cwsent.com> To: Stefan Blachmann X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: 5DB098694E X-Spamd-Result: default: False [2.37 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; NEURAL_SPAM_MEDIUM(0.65)[0.645,0]; NEURAL_SPAM_SHORT(0.57)[0.569,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[42.134.6.74.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; IP_SCORE(1.66)[ip: (4.59), ipnet: 74.6.128.0/21(2.12), asn: 26101(1.70), country: US(-0.09)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 17:51:32 -0000 On 2018-Nov-18, at 04:11, Stefan Blachmann wrote: > The inconveniences that the new swapping strategy causes are a regular > topic in the FreeBSD forums. > > Desktop users complain about lagginess, server users complain of long > delays because server processes intended to be kept in memory for > quick response times got swapped out and need to be swapped in again, > resulting in outrageously poor server performance in spite of plenty > of unused memory. I've no clue of the variations in workloads involved for various folks, but I only see swapping/paging once free memory is low in my UFS based contexts. (I've not used ZFS in a long time.) I do not see free RAM decreasing without known, expected use of the RAM. Mostly I've had to learn how late it may be before pages for cached information explicitly moves back to free, no matter if that involves paging/swapping out or not. As I understand what Mark Johnston reported, he said that there is no preemptive paging/swapping: "FreeBSD will only ever swap when there is a free page shortage" Moving between Active and Inactive does not of itself involve paging/swapping. So that part of his description is a different issue. So the issue may trace back to why there ends up being a prior free RAM shortage and/or when pages are moved back to RAM after such a shortage. I believe my report above is consistent with what Mark Johnston reported about the modern algorithm(s) involved. > Turning off swap completely, as Cy Schubert suggests, is strongly > discouraged in the forums, as it can lead to kernel panicking because > of being unable to swap out in critical kernel memory shortage > situations, leading to the risk of very serious filesystem > corruption. > > However, Cy Schubert is probably right when stating that the new > swapping strategy resembles the 1960s-1980s industry's main swapping > strategy. Important parts of "new" way seems to have been in place since after 4.4BSD (so BSD 5.0 and later) . . . The book "The Design and Implementation of the FreeBSD Operating System" (2nd edition) states (page labeled 296): QUOTE: The FreeBSD swap-out daemon will not select a runnable processes to swap out. So, if the set of runnable processes do not fit in memory, the machine will effectively deadlock. Current machines have enough memory that this condition usually does not arise. If it does, FreeBSD avoids deadlock by killing the largest process. If the condition begins to arise in normal operation, the 4.4BSD algorithm will need to be restored. END QUOTE. (I've not found vm.pageout_oom_seq in the book. It is for controlling how much effort is put into freeing RAM before kills start, and so, indirectly, the elapsed time that happens before those kills start.) I'm not sure what specific changes that are newer might be under discussion. > The bad thing is now, that nowadays memory is no longer scarce and > people can dimension their memory such that under normal circumstances > there will never be any need to swap. My typical use is apparently not normal. I'd agree with that. > So I guess the unwillingness of the developer team to add an option > like "NoPreemptiveSwapping", which disables swapping out as long as > there is free physical memory available, is of psychological nature. Unsure how to interpret this given: "FreeBSD will only ever swap when there is a free page shortage" > Lacking such an option, there is still the possibility to use rctl to > disable swapping for particular users, processes, jails etc to > mitigate the problems caused by the new swapping strategy to some > degree. Whatever is going on for this, it seems a more technical identification of what it is would be needed in order to get to the right context. (It may be non-trivial to identify.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)