From owner-freebsd-hackers@freebsd.org Sat Nov 24 17:16:04 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 057CF1104E0E for ; Sat, 24 Nov 2018 17:16:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D71F83A62 for ; Sat, 24 Nov 2018 17:16:03 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1543079754; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=D3CG3EG9WGhxlKhtXDnXnNjKiBb68c35d3vK8JXv5JcLqg0FoNTlRZtr4h8HW1Mgfru2vWCWhoKZu OndoPVy5Czc6WhvdR9zqN9h3Y37mGRaLT/AEW941bRC2LZXYsXeTRSbpgkP89n+V/DnvJaclDxpbQG H4vJpdzxF1Bx5yEd8uXd4oQTfB0pNY8uMK31jekvVM/g0vsYoLtrQhf47e/549Oa7Nexc61Sejn/PS wEJDzytXLy+RsIgQbjF6NBaUEoWlyv0UHhaOUoyITavA6eXzlvMC7GFt9D6l+ODAX0Vb+vsJDeyS1m Qb9tWAhWnt6mCEhCemm4+g3XVqvvIOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=wQkwjkU34N3gxGXRlTRbFm2uaeKhB/Eu2fiapvvuO7w=; b=KnM1skiSXj+4DgEMNnD1sdL0mJntx8ZT3MEllUk0OqXmrMVyNT1Dt0Jzga2c9hI0ZLLKzeEOdZIJC bVpQCnhO2vdQNa+gWONHnjq30QtWZuhKR+w63on8HUiXjwEIOv6VOH+hlJNlt2JSsRF4pvgdojM7AL EX31orFLGEXJhAsYg/web1AG/Qw/lL/pkazmkSUA3519FLxmPdTAIOy9RdforFv4VfuBtbVx71xOEj qHcfbotbsnsinTUEJb/0KU7o/P+KBbGpNC/BdW6CjW51HQySogA5vs6m8eUwPLT5d0hXEZo+Bh5ZHM NLZprLh0Vj/jBmREs7YPRSn17ziELvg== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=wQkwjkU34N3gxGXRlTRbFm2uaeKhB/Eu2fiapvvuO7w=; b=bHWg4jDB7ZpqfyhETVYZ0QQrRqIVEtamKaEl4eXR8GfQ0HTeaG/mgWsshJn2vgTL0WMrwPPFJf7pF exg//YyuH5ptmu0nv1hvRSGnglrgBmgpuabmmZE3cprL6VUYLUV1emX8PlAAFEgVWtQr5Jm6qXYnPx 2jfxlGWuSplbZbVDCgTxlBXSaJkHHVO8b3kdj1U3CDXL0zZB57lV2YL025AI4+2klpD3v+77Pc8YNL eRZz1hJ37cp9jnMOc6NX1uvbMuzqN8FBC6K1t1kp1r0v3NJkq3jP/4Qi9giNrbCkhK96Gvmhc8t/28 1gZM2tgR6GqyRoeT1y/Zz2xu+EYy3Jg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 95cc4eb8-f00c-11e8-8a28-a1efd8da9a94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 95cc4eb8-f00c-11e8-8a28-a1efd8da9a94; Sat, 24 Nov 2018 17:15:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wAOHFlnk025921; Sat, 24 Nov 2018 10:15:47 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1543079747.36737.6.camel@freebsd.org> Subject: Re: 13-CURRENT: several GB swap being used despite plenty of free RAM From: Ian Lepore To: Stefan Blachmann , Cy Schubert Cc: Wojciech Puchar , freebsd-hackers Hackers , Rebecca Cran , Mark Johnston Date: Sat, 24 Nov 2018 10:15:47 -0700 In-Reply-To: References: <201811180154.wAI1smhg049214@slippy.cwsent.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 3D71F83A62 X-Spamd-Result: default: False [1.78 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.68)[0.683,0]; NEURAL_SPAM_MEDIUM(0.60)[0.599,0]; NEURAL_SPAM_LONG(0.50)[0.497,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US] 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: Sat, 24 Nov 2018 17:16:04 -0000 On Sun, 2018-11-18 at 13:11 +0100, 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. > > 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. > 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. > > 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. > > 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. > Well that was a nice little rant, I hope you feel better. Perhaps it has cleared your mind enough to eventually realize that I gave you the command to do exactly what you sarcastically suggest "the developer team" is unwilling to implement. It's still there, in the quoted text below, not quite completely obscured by the typical word soup of irrelevancies from the usual source which sidetracked this thread into a discussion about swapping, which isn't involved in any way (and served with a side of mixed top and bottom posting to make it almost impossible to follow the conversation). -- Ian > On 11/18/18, Cy Schubert wrote: > > > > In message , Mark > > Millard via f > > reebsd-hackers writes: > > > > > > On 2018-Nov-17, at 16:13, Mark Johnston > > > wrote: > > > > > > > > > > > > On Sat, Nov 17, 2018 at 04:59:48PM -0700, Ian Lepore wrote: > > > > > > > > > > On Sat, 2018-11-17 at 22:52 +0100, Wojciech Puchar wrote: > > > > > > > > > > > > freebsd will not swap with that lots of free ram. > > > > > > but it's 90GB free NOW, how about before? > > > > > > > > > > > Your information is outdated. For at least a couple years now > > > > > (since > > > > > approximately the 10.1 - 10.2 timeframe is my vague > > > > > estimate), freebsd > > > > > will page out application memory that hasn't been referenced > > > > > for some > > > > > time, even when the system has no shortage of free memory at > > > > > all. > > > > No, FreeBSD will only ever swap when there is a free page > > > > shortage. > > > > The > > > > difference is that we now slowly age unreferenced pages into > > > > the > > > > inactive queue, which makes them candidates for pageout and > > > > subsequent > > > > eviction.  With pageout_update_period=0, anonymous memory won't > > > > get > > > > paged out unless there's a shortage of inactive pages, or an > > > > application > > > > calls madvise(MADV_DONTNEED) on a range of memory (which moves > > > > any > > > > backing pages to the inactive queue). > > > Swapping is built on top of paging as I understand. The system > > > can page without swapping but can not swap without (effectively) > > > paging to implement the swapping, if I understand right. If I > > > understand right, swapped-out means that kernel stacks have > > > been written out and have to be loaded back in RAM before the > > > process/threads can even run. (I might not understand.) > > > > > > If I've got that right, are there distinctions here for > > > paging that is not part of swapping vs. actual swapping > > > (and its use of paging)? Saying that something does not > > > swap does not necessarily imply that it does not page: > > > it still could have paging activity that does not include > > > moving the kernel stacks for the process to backing media? > > This is generally the old-school definition, IIRC third year comp > > sci, > > original BSD definition, which was also the way IBM defined it for > > MVS. > > (IBM also virtually swapped out address spaces, not written to > > DASD, as > > a means to deny CPU cycles through the scheduler not given the > > chance > > to consider the tasks (threads) in the address space). > > > > You can disable swapping by setting vm.swap_enabled=0. > > > > > > > > > > > At times I have trouble interpreting when wording goes back > > > and forth between swapping and paging, both for the intended > > > meaning and for the technical implications. > > > > > > > > > > > > > > > > > The advice I was recently given to revert to the old behavior > > > > > is: > > > > > > > > > >   sysctl vm.pageout_update_period=0 > > > > > > > > > > I've been using it on a couple systems here for a few days > > > > > now, and so > > > > > far results are promising, I am no longer seeing gratuitous > > > > > swapfile > > > > > usage on systems that have so much free physical ram that > > > > > they should > > > > > never need to page anything out. I haven't yet pushed one of > > > > > those > > > > > systems hard enough to check what happens when they do need > > > > > to start > > > > > proactively paging out inactive memory due to shortages -- it > > > > > could be > > > > > that turning off the new behavior has downsides for some > > > > > workloads. > > > > > > > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com > > > ( dsl-only.net went > > > away in early 2018-Mar) > > > > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to > > > "freebsd-hackers-unsubscribe@freebsd.org" > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX:     Web:  http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freeb > > sd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd > .org"