From owner-freebsd-current@freebsd.org Sun Sep 15 07:49:04 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE630E4EE2 for ; Sun, 15 Sep 2019 07:49:04 +0000 (UTC) (envelope-from freebsd-current@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46WM2R2Qpfz45FB for ; Sun, 15 Sep 2019 07:49:02 +0000 (UTC) (envelope-from freebsd-current@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id x8F7mpp7090548 for ; Sun, 15 Sep 2019 17:48:51 +1000 (AEST) (envelope-from freebsd-current@sentry.org) Subject: Re: poudriere, swap full and top says memory is free ? To: FreeBSD Current References: <20190914173805.GC2863@home.opsec.eu> <20190914182857.GM96402@funkthat.com> From: Trev Message-ID: Date: Sun, 15 Sep 2019 17:48:51 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Sun, 15 Sep 2019 17:48:51 +1000 (AEST) X-Rspamd-Queue-Id: 46WM2R2Qpfz45FB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-current@sentry.org designates 210.8.237.106 as permitted sender) smtp.mailfrom=freebsd-current@sentry.org X-Spamd-Result: default: False [-4.22 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[sentry.org]; IP_SCORE(-2.92)[ip: (-8.23), ipnet: 210.8.0.0/15(-4.18), asn: 2764(-2.18), country: AU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2764, ipnet:210.8.0.0/15, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Sun, 15 Sep 2019 07:49:04 -0000 Don Lewis wrote on 15/09/2019 11:31: > On 14 Sep, John-Mark Gurney wrote: >> Kurt Jaeger wrote this message on Sat, Sep 14, 2019 at 19:38 +0200: >>> - a poudriere build >>> - of a list of ports >>> - on 12.0-RELEASE-p10 >>> - on a 4 core+4 hyperthreads CPU, an Intel(R) Xeon(R) CPU E3-1230 v6 >>> @ 3.50GHz >>> - with 32 GB RAM >>> - zpool with 2x 500 GB SSDs as a mirror >>> >>> and right now, this can be seen: >>> >>> last pid: 90922; load averages: 5.02, 5.14, 5.73 up 0+03:53:08 19:31:05 >>> 82 processes: 6 running, 76 sleeping >>> CPU: 60.6% user, 0.0% nice, 2.1% system, 0.0% interrupt, 37.3% idle >>> Mem: 4598M Active, 2854M Inact, 11G Laundry, 6409M Wired, 6375M Free >>> ARC: 3850M Total, 1721M MFU, 2090M MRU, 665K Anon, 19M Header, 19M Other >>> 3406M Compressed, 3942M Uncompressed, 1.16:1 Ratio >>> Swap: 18G Total, 18G Used, 396K Free, 99% Inuse, 68K In >>> >>> So: Swap is full, approx. 6 GB memory is reported as free. >>> >>> This is surprising. Can I somehow tune this in any way, so that >>> the memory available is used for the build ? Or is the problem somewhere >>> else ? >> >> Are you sure that this hasn't just recently completed a large link of >> something like Chromium? There are known to be compiles that can take >> many GB's of memory and if they recently exited, there hasn't been time >> to swap stuff back in... or is this the steady state over the entire >> compile? > > This is sort of an odd case. I suspect that swap filled and then a > process that was using a large amount of memory but no swap exited or > was killed. That freed a bunch of memory, but no swap. > > I'm pretty sure that when a memory page is paged back in from swap, that > the copy in swap is retained and not deallocated. Under memory > pressure, that allowed the page to be stolen without having to write it > back out to swap again, unless it was re-dirtied in the meantime. Don't forget swap fragmentation could conceivably cause oom even if there is swap appearing to be available. sysctl vm.swap_fragmentation is interesting.