From owner-freebsd-hackers@freebsd.org Sat Nov 24 17:47:20 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 781A3110EFE6 for ; Sat, 24 Nov 2018 17:47:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43FC68494C; Sat, 24 Nov 2018 17:47:19 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id Qc1MgftzeP7x2Qc1OgFtgS; Sat, 24 Nov 2018 10:47:11 -0700 X-Authority-Analysis: v=2.3 cv=X9GD11be c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=JHtHm7312UAA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=CjxXgO3LAAAA:8 a=YVOhz5M6AAAA:8 a=SLG1KRGDAAAA:8 a=MUQfBbhXRRlCCULTAwgA:9 a=YRp9IFY1wmEaPIZV:21 a=k3DeAcpCFCNX51e_:21 a=wPNLvfGTeEIA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=sbbTL3E6IKcx-RquDtO-:22 a=-TBaU1e9WpdkKBzYXnwo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id AD71A19C3; Sat, 24 Nov 2018 09:47:07 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id wAOHl63U079943; Sat, 24 Nov 2018 09:47:06 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id wAOHl4Kx079905; Sat, 24 Nov 2018 09:47:05 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201811241747.wAOHl4Kx079905@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: Stefan Blachmann , Cy Schubert , Wojciech Puchar , freebsd-hackers Hackers , Rebecca Cran , Mark Johnston Subject: Re: 13-CURRENT: several GB swap being used despite plenty of free RAM In-Reply-To: Message from Ian Lepore of "Sat, 24 Nov 2018 10:15:47 -0700." <1543079747.36737.6.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 24 Nov 2018 09:47:04 -0800 X-CMAE-Envelope: MS4wfBe0jdoPj9lmqjH9MyXQ4YdAnInb8nFY/qe5mwbmWHesqWmT+1AlFKagwjwAsbsc4IWm1WqKkQxsfgzihxb2n917hk1x+Vgz0Q6tG66dtmvmMzj5/UO1 0ylZsSsbUX+PJidNgu5zoX2LvbiixtJ/4fZKU06Biq5HRUjnkOcoXRWaSHqM7JMbkYcYqBXJc+9yzKlF5sLu/luZTdgErmKejPOpbF90YDxE+jt3LmTsl7H8 HuP4DG1EjrHQ0IKasJr6tK83CQJyBuNwszsoRVObJaYG8GyD3FdSfzn2Zjaz9C5WCaz6AoweuiCWfWMv+q44rvu/h7niF1aTT6P29udGi14= X-Rspamd-Queue-Id: 43FC68494C X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; IP_SCORE(-0.96)[ipnet: 64.59.128.0/20(-2.60), asn: 6327(-2.08), country: CA(-0.09)]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.93)[-0.929,0]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] 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:47:20 -0000 In message <1543079747.36737.6.camel@freebsd.org>, Ian Lepore writes: > 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 There was some question about swapping, which I had answered. My point was: this technology has been around for decades and that almost all operating systems manage memory in a similar fashion -- I believe my answer was a little more subtle and wordy, put bluntly: this is CS 101 and everyone here should understand it. It doesn't pay to be subtle. Bluntly: it's virtually done the same everywhere. So what is the problem? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > > 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"