From owner-freebsd-stable@freebsd.org Sun Jun 28 01:04:49 2020 Return-Path: Delivered-To: freebsd-stable@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 A955833911C for ; Sun, 28 Jun 2020 01:04:49 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from gate.utahime.jp (gate.utahime.jp [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49vXTW5Xw5z4g81 for ; Sun, 28 Jun 2020 01:04:47 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gate.utahime.jp (Postfix) with ESMTPS id A1F1386D9 for ; Sun, 28 Jun 2020 10:04:37 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1593306277; bh=vU7Gg7AKtbHQ7MKJmaRhCr+2eQTKfKsFxKJAC6RCDLc=; h=Date:To:Subject:From; b=i+hzHMpFBO1xiDCoRqh92OP3tibrwkMj9i6FAloFuAEin5wSKpvKZbEoP7VAxJYmq pgLDTjy+IbsVt8HXBFuEKWgZUArLx6TH3IowmmuDrCst5i1wct6ScvI57YIozk6u3y wSGJSsdFLhpQGO/B3TZm7wLePvAZT9AwBLVU63F0BsjHT6L9L2StnrD68QqqgqC0VB gIUhYuAIYPGMl0FKKGbLq9+nTHPano5R1w+1AqYVUwm5UNt0jtGGysxDYkkHwlCKLp XGl8g4rB984SpxFP/4dw4C4r4OX5RjTT6/6hWLyXu66/sJg8i1Tcu9Uzy/e8LiVziU BV6cbuDU7K52Q== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 4CCA95AF18; Sun, 28 Jun 2020 10:04:36 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at eastasia.home.utahime.org Date: Sun, 28 Jun 2020 10:03:53 +0900 (JST) Message-Id: <20200628.100353.961960407054898629.yasu@utahime.org> To: freebsd-stable@freebsd.org Subject: `efivar -l` fails on UEFI booted 11.4-RELEASE From: Yasuhiro KIMURA X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49vXTW5Xw5z4g81 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=i+hzHMpF; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-1.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.972]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[utahime.org]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-0.05)[-0.047]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 01:04:49 -0000 On UEFI booted 11.4-RELEASE system `efivar -l` fails as following. root@rolling-vm-freebsd3[160]# uname -a FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@rolling-vm-freebsd3[161]# efivar -l efivar: Error listing names: No such file or directory root@rolling-vm-freebsd3[162]# It also happens with latest (20200625) 11-STABLE snapshot, but not with either 12.1-RELEASE or 13-CURRENT. --- Yasuhiro KIMURA From owner-freebsd-stable@freebsd.org Sun Jun 28 02:21:28 2020 Return-Path: Delivered-To: freebsd-stable@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 6889833C16E for ; Sun, 28 Jun 2020 02:21:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vZB00VSTz3W9Y for ; Sun, 28 Jun 2020 02:21:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id DDFF1263E2 for ; Sun, 28 Jun 2020 02:21:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f180.google.com with SMTP id c30so8531580qka.10 for ; Sat, 27 Jun 2020 19:21:27 -0700 (PDT) X-Gm-Message-State: AOAM532S27z7qX+rPpSq8EA1iOZtkohds+L+aeV51mc+O7CFUzwMTN+T SFDycYCOy44lab5Jk8f/+DCp0W2BuTj7WFp6Yyc= X-Google-Smtp-Source: ABdhPJzPtmJxbmWF8gtxHBVSOTZFTmguNE45B3uc9SN+CDM5MFaR6eJwDBi18b0YnN9iTUjji8uujjRdCvVFFZc++EA= X-Received: by 2002:a37:bcb:: with SMTP id 194mr9894699qkl.103.1593310887465; Sat, 27 Jun 2020 19:21:27 -0700 (PDT) MIME-Version: 1.0 References: <20200628.100353.961960407054898629.yasu@utahime.org> In-Reply-To: <20200628.100353.961960407054898629.yasu@utahime.org> From: Kyle Evans Date: Sat, 27 Jun 2020 21:21:10 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE To: Yasuhiro KIMURA Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 02:21:28 -0000 On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA wrote: > > On UEFI booted 11.4-RELEASE system `efivar -l` fails as following. > > root@rolling-vm-freebsd3[160]# uname -a > FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > root@rolling-vm-freebsd3[161]# efivar -l > efivar: Error listing names: No such file or directory > root@rolling-vm-freebsd3[162]# > > It also happens with latest (20200625) 11-STABLE snapshot, but not > with either 12.1-RELEASE or 13-CURRENT. > Hi, This should be an easy fix. :-) EFI Runtime Services on FreeBSD ("EFIRT") wasn't necessarily globally stable until right around 12.0. For 11.x, you'll need to `kldload efirt` or add `options EFIRT` to your kernel config before efivar/efibootmgr become usable. Thanks, Kyle Evans From owner-freebsd-stable@freebsd.org Sun Jun 28 03:24:08 2020 Return-Path: Delivered-To: freebsd-stable@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 13D9533DD9D for ; Sun, 28 Jun 2020 03:24:08 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from gate.utahime.jp (gate.utahime.jp [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49vbZG0Jvbz3Ynd for ; Sun, 28 Jun 2020 03:24:05 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gate.utahime.jp (Postfix) with ESMTPS id 568F79D7E for ; Sun, 28 Jun 2020 12:24:02 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1593314642; bh=c8X704HIlGXSdS7E5sdCKz3cyJz5N/BRjPwz5mS71bc=; h=Date:To:Subject:From:In-Reply-To:References; b=lBqysAeiZ+5DZ3xQWQD6QCPksaFxgwg/OlgZJzrjl+WCT0Quu+MjD+CvOzP+Ybdsr uYtrIeNrg1GuX5xIIFcXErpI4v1Dhwsj8EaigBOhs5V6nItBD3b6WJKKSieTdB65nG 8eOC+vUCdWfL29nwKkj5NmN6vAuXc2hoIhG3WIhZW18GyIcWKLcbxleHHXwcyEqPDs n9VTHqOFIblu2SgoHSM5LG8D1tB8WMp+X+lWttTQuRSWzgbInRM2P5NsS6zk1kxqhm ZOcEMRupv5RPbccANuN4oLV0SLPIFZFTvPcZW7hixQ8nNSUKgO0LvpmY3arfO+49Xs /4d0AzPPx1SOg== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 492225B4B1; Sun, 28 Jun 2020 12:24:00 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at eastasia.home.utahime.org Date: Sun, 28 Jun 2020 12:23:46 +0900 (JST) Message-Id: <20200628.122346.912505386040690060.yasu@utahime.org> To: freebsd-stable@freebsd.org Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE From: Yasuhiro KIMURA In-Reply-To: References: <20200628.100353.961960407054898629.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49vbZG0Jvbz3Ynd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=lBqysAei; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-1.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.970]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[utahime.org]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-0.05)[-0.054]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 03:24:08 -0000 From: Kyle Evans Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE Date: Sat, 27 Jun 2020 21:21:10 -0500 > This should be an easy fix. :-) EFI Runtime Services on FreeBSD > ("EFIRT") wasn't necessarily globally stable until right around 12.0. > For 11.x, you'll need to `kldload efirt` or add `options EFIRT` to > your kernel config before efivar/efibootmgr become usable. Thank you for reply. After loading efirt.ko `efivar -l` succesfully lists UEFI environment variables. --- Yasuhiro KIMURA From owner-freebsd-stable@freebsd.org Sun Jun 28 07:02:44 2020 Return-Path: Delivered-To: freebsd-stable@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 E1C59343382 for ; Sun, 28 Jun 2020 07:02:44 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vhQX0kVsz42RY; Sun, 28 Jun 2020 07:02:43 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-lf1-x142.google.com with SMTP id u25so7284284lfm.1; Sun, 28 Jun 2020 00:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JUUerYeVtNLXu7DaYPLwz5ItmGL7DZjPtfvVSQ+Nf/c=; b=t0c3fMz6mqpSdkK48OiseewNwEgrz2j/NS595kVFuNfLz9mkrH7evFKE4VY6bQwYkn PlIndiq5L3wXi06+fy96LWsbVR9PAuyd0zaZ9gYUtypgIJgTIezIxMxjUH+AhBcero7p geCEczH9KrCGFEl/UmSDtNobulsMYzPk3QAjtNiRrtia++9lGOKNRhRAM80/WEP90Qez VhxY3GJ9jZoh8S1pfX4xcQW4/TScbfFSPCORKLlgRWCIUdSN4zQYL+L29Mekzd+gycQO GY+KwuqC9EMTrn2kOGSGjMvxiBo/PkuJAop1mXFgYLTikGp/Sb42UN0gRFw7wCFokoFk qGIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=JUUerYeVtNLXu7DaYPLwz5ItmGL7DZjPtfvVSQ+Nf/c=; b=uniE0jQpMHHGfb4PRNp7Dfw27JBzRy73HvRSPMnqVRNUcyQrlrjy+9L53vQyij2Go7 t5bHW3HFFzKF5yNZClgtbhd/uAw8IQ7gsaW6SCWeZha9EGdct0oIDobNiJNm5nWqjXRq 1Hfx6Mu56ZCvD1DUXPedBHVXLft4sufB62/h0QaTaFPX2TgkO7YF7Cv3NI6s+6WoHOvi W2OxiHfQjIs9v21r7Wl1XeMe8XljQbf0oHpXdv5MYcrpPZsQJd8+4JLysBCAxrTCDCIh qpD5UIu8HwEJbLwqVd919VbOdpQuZYLr90d/KBe6x0Mw9pdQeWCMpV9c2SCBS3/KD7Fj XMUg== X-Gm-Message-State: AOAM532i4c1RRDyFoCRgW7zAxmiFQGfMha3Gm0zf8o2YSntRyJWewdXf facDG5V30kRjeHqQrbSL1B/KdXcrqxnrJh8L66/3Yvkz X-Google-Smtp-Source: ABdhPJyIsZGJlnJfgobrOJsf7eLlcUfjGREX35Udxyx0i/p0psLBvJIGcpG69/TaK8qwZXBvBo0APyvN0ufY9xgcB9g= X-Received: by 2002:a05:6512:10d3:: with SMTP id k19mr6324517lfg.78.1593327761858; Sun, 28 Jun 2020 00:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4703:0:0:0:0:0 with HTTP; Sun, 28 Jun 2020 00:02:41 -0700 (PDT) Reply-To: dwilde1@gmail.com In-Reply-To: References: <20200625000410.GA10210@eureka.lemis.com> <20200625025248.GB10210@eureka.lemis.com> <20200626102331.GA6406@server.rulingia.com> <1140215402.1.1593187896838@localhost> From: Donald Wilde Date: Sun, 28 Jun 2020 00:02:41 -0700 Message-ID: Subject: Re: swap space issues To: Ronald Klop Cc: Bob Bishop , Peter Jeremy , "Greg 'groggy' Lehey" , freebsd-stable , ericbsd Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49vhQX0kVsz42RY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=t0c3fMz6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2a00:1450:4864:20::142 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; HAS_REPLYTO(0.00)[dwilde1@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-0.92)[-0.917]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::142:from]; NEURAL_SPAM_SHORT(0.19)[0.193]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 07:02:44 -0000 On 6/27/20, Donald Wilde wrote: > On 6/26/20, Ronald Klop wrote: >> >> Van: Bob Bishop >> Datum: vrijdag, 26 juni 2020 17:18 >> Aan: Peter Jeremy >> CC: Donald Wilde , freebsd-stable >> >> Onderwerp: Re: swap space issues >>> >>> >>> >>> > On 26 Jun 2020, at 11:23, Peter Jeremy wrote: >>> > >>> > On 2020-Jun-25 11:30:31 -0700, Donald Wilde wrote: >>> >> Here's 'pstat -s' on the i3 (which registers as cpu HAMMER): >>> >> >>> >> Device 1K-blocks Used Avail Capacity >>> >> /dev/ada0s1b 33554432 0 33554432 0% >>> >> /dev/ada0s1d 33554432 0 33554432 0% >>> >> Total 67108864 0 67108864 0% >>> > >>> > I strongly suggest you don't have more than one swap device on >>> > spinning >>> > rust - the VM system will stripe I/O across the available devices and >>> > that will give particularly poor results when it has to seek between >>> > the >>> > partitions. >>> > Based on all recommendations on this thread (thanks, guys!), I've > rebuilt my i3 mule with exactly one 16G partition, as it has only > 'spinning rust' for a disk. My loader.conf has > kern.maxswzone=4200000 and ccache is fully active and working for both > root on tcsh and users on sh. That appears to be successful. this is still a MBR-based system, not GPT, due to BIOS issues, but it's a 'choose my battles' situation. > > I have yet to try synth again. I'm doing buildworld/buildkernel for > 12-STABLE, but evidence so far is good. 'top -t' is actually happy, > showing 16G (grog?), so I'll try firing up synth after another hour or > so on the latest fetch of the ports tree. Top appears to have gone south again. I give up, Greg! 'pstat -s' _is_ happy. Synth is still crashing hard, same issue. As I said in freebsd-ports on my thread about 'stable postgresql11', pg11 didn't like synth's request that I create a different directory because /usr/ports/distfiles didn't exist. Doing so and adding the DISTFILES to make.conf caused all kinds of problems. I am currently (I hope) building a successful pg11-server, but I've restored /usr/ports/distfiles and before I go to bed tonight I hope to kick off another synth run. This failure happened with three builders and three tasks per builder. The symptom, multiple times, has been that llvm80 takes forever and then causes the swap failure even though pstat -s is happy AND loader conf kern.maxswzone (=4200000) is sufficient for my 16G partition. I've tried installing llvm80 as a pkg, but that didn't help. The swap stays at zero usage, and then goes almost instantaneously to OOM. The only bit of advice I'm not completely compliant with is the use of a 16G swap partition where I was advised to set max to 8G. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Sun Jun 28 07:52:08 2020 Return-Path: Delivered-To: freebsd-stable@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 DC495344381 for ; Sun, 28 Jun 2020 07:52:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vjWX5b83z44n0; Sun, 28 Jun 2020 07:52:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id A209729979; Sun, 28 Jun 2020 07:52:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [10.10.156.45] (unknown [45.85.81.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4574D6E388; Sun, 28 Jun 2020 09:52:07 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A88B789B-1173-45FE-8100-5B7DBB51F60B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE Date: Sun, 28 Jun 2020 09:52:00 +0200 In-Reply-To: Cc: Yasuhiro KIMURA , FreeBSD-STABLE Mailing List To: Kyle Evans References: <20200628.100353.961960407054898629.yasu@utahime.org> X-Mailer: Apple Mail (2.3445.104.14) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 07:52:08 -0000 --Apple-Mail=_A88B789B-1173-45FE-8100-5B7DBB51F60B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Jun 2020, at 04:21, Kyle Evans wrote: >=20 > On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA = wrote: >>=20 >> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following. >>=20 >> root@rolling-vm-freebsd3[160]# uname -a >> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD = 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 = root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >> root@rolling-vm-freebsd3[161]# efivar -l >> efivar: Error listing names: No such file or directory Perhaps the efivar utility could suggest loading the module in this = case? -Dimitry --Apple-Mail=_A88B789B-1173-45FE-8100-5B7DBB51F60B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXvhMIAAKCRCwXqMKLiCW o1b5AJ90c+ab77aGzlw6XRSnfFov9RtwqgCeMGEkpiT2ZdMe809OruLSyRgwA4M= =CCEO -----END PGP SIGNATURE----- --Apple-Mail=_A88B789B-1173-45FE-8100-5B7DBB51F60B-- From owner-freebsd-stable@freebsd.org Sun Jun 28 09:49:19 2020 Return-Path: Delivered-To: freebsd-stable@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 484C1346849 for ; Sun, 28 Jun 2020 09:49:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vm6k3Sn3z4BCy for ; Sun, 28 Jun 2020 09:49:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id b4so12766376qkn.11 for ; Sun, 28 Jun 2020 02:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N/gq/JCKJQ7lWLteKwE1vA8ICt3E7gZAULegJPKxF9U=; b=qIJ3I5ADJ7ZVyOEP3A+E3jbhrG7cOTNU4JDnVnN9yplMRKKCpWxtb1NORsX15OD+LO rIhvm6jw/UoVO6tXalRG4E07wPjThz2gUhUhmqF2Mz8EXK2Dutrag4Uf8NsuDzUu9AKk KNp9KOeuA2prRY9qhp6K5qaNKh43azSEQDkF2MPuAy+3ejKYxeyiDh5mFnKVUoB7lrCc mx0//FAvzejWZ1cE5VP2Acw4HZ2VV42SG7pWtCh2tou4HvqcVhbv7g3l4AjpL+i9qWKn vCE4jj2BIxOPADvRuQOKrvF/67cQNlINSWQnLKmnKvHc8TEZJWGOtJXeu+czdCHsk8IY LTRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N/gq/JCKJQ7lWLteKwE1vA8ICt3E7gZAULegJPKxF9U=; b=kSuL31CQguDkx8VKI2JsXIWyw5L7CQN+DOcS8VRonA6QQ9dFwB0ThmnOcnBBnFMZea i3EhAccXL6yFxLBveT6fMGKXwH2o/OxQvXGxGFr8uS/XpWXXN4mwPZPy+D9FkmV4Rw0F yufaYv0kBlO9pMSW+eAX04DOxbb3luuvKTazqxzcB/moqfhILbvG4+rhHwHb9wsdnFMX Chsr0x+cVlZzksW/KPLxO5OOvvsqEWQ5sVpZufoMM0j5QJElQI1rom18X2vVC4CFaCWh a2JN2k7F9CtiZArM/pGREcoyqp+GDn/ydW31dOyhe81j0tL4z81lmIqc94ASaxn+Ovh5 TISA== X-Gm-Message-State: AOAM531NTkNWAxwabtdRDbUorkP/jVPFUSpsHspWCS8h6MgFtlUP5tZy 98KVRJKJaAOD6OSKgU6BOx+9f+QX9gNp3uQbEJXdgg== X-Google-Smtp-Source: ABdhPJw3bovCidDshggj4dyrgnczJJ8pYkVVK4DwrFlJGxFwFjbeGJ6X8RKDZuGI494gLfkf5tuJox4OlPFdGr+Z4GQ= X-Received: by 2002:a37:4d97:: with SMTP id a145mr10102160qkb.380.1593337756696; Sun, 28 Jun 2020 02:49:16 -0700 (PDT) MIME-Version: 1.0 References: <20200628.100353.961960407054898629.yasu@utahime.org> In-Reply-To: From: Warner Losh Date: Sun, 28 Jun 2020 03:49:04 -0600 Message-ID: Subject: Re: `efivar -l` fails on UEFI booted 11.4-RELEASE To: Dimitry Andric Cc: Kyle Evans , Yasuhiro KIMURA , FreeBSD-STABLE Mailing List X-Rspamd-Queue-Id: 49vm6k3Sn3z4BCy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=qIJ3I5AD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.878]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.64)[0.642]; NEURAL_HAM_LONG(-0.93)[-0.929]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72a:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 09:49:19 -0000 On Sun, Jun 28, 2020, 1:52 AM Dimitry Andric wrote: > On 28 Jun 2020, at 04:21, Kyle Evans wrote: > > > > On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA > wrote: > >> > >> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following. > >> > >> root@rolling-vm-freebsd3[160]# uname -a > >> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD > 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > >> root@rolling-vm-freebsd3[161]# efivar -l > >> efivar: Error listing names: No such file or directory > > Perhaps the efivar utility could suggest loading the module in this case? > The trouble I'd that this error also means other things too. It's a lot more than changing the printf here. Warner > From owner-freebsd-stable@freebsd.org Sun Jun 28 20:16:13 2020 Return-Path: Delivered-To: freebsd-stable@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 63E09354702 for ; Sun, 28 Jun 2020 20:16:13 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49w2242Z1Yz3Y2l; Sun, 28 Jun 2020 20:16:12 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id m26so7924274lfo.13; Sun, 28 Jun 2020 13:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=BFQCMJq3cB9YbbObeYu8c15aDz2v7t7wRn+/KCdG8+4=; b=Vewr3HaYbWWRPWGHwyHMYpmtqt7WmNI1oNc1jW2j/lMYpKR+5/VfNflgnphAXXiSgp uWNfdmr+tRJPAKLenqZ2UPhiIOFffQ3OaBQDRoxkfWnL4ZtLXi2FarSMUMY2HYyE67xG nrLec3JGIvzA10QuCtFKCKIhShPKCx6ulgStiAamn5qSM95wZxHPEUawCgbmI8cAS+a4 cURGtzEnXyVhU+2RF7EGFGUT9oExxe+dZlL70Tua4SucUo7XeUi4nXTqo3IpPS/nZZl8 YiOZqy2Tpj01vDqGQA/hB2cHG6q+qR/ta46u3zgNlPexQ+dLQ1g3qBFQ1UAfLwk3XnF9 8Hxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=BFQCMJq3cB9YbbObeYu8c15aDz2v7t7wRn+/KCdG8+4=; b=AUOaC7rsdyP/GTLdbNsdb+z8h5Ow/+Ljo/LkhNazT7jmfQeePeR/LjScy1oC5qrxfC S+7bdBD7kIHNz86R8CTjY0nAMiAJYnkmTvUnYUZpvS8fnu02xDIXliJHLDM02SF5p2YX GBXeBwD5kGYFUpds4BlS5v4jbqyHJd9SfEWwl4k0V1HwQ8F3VUNb7UBYdNE7Nnut57Kt FFaqaCpG7DwLgPPnZ3sPZK/O7jqV9vBiL9tMC3EBRGPnThLJvOzztnvgSQ4pj3qwr4bo TVRC7qXJqa9DpUs1Qr/VgSvxlxSIi4dKVoPekOUhwzqUdkWXkH66gbc2/u7pkRO1hUso w62Q== X-Gm-Message-State: AOAM531+lqFrOwirumA/SS9+Tsf6hfsLA+n4xyaZek2Kd6wiOiHCdhfG CdaOZfCE21nnQW3RK6wXlTXd4ZXlNjz0dvLvMyMY9V1T X-Google-Smtp-Source: ABdhPJx0lFbSvOVgXx8fkNL5fTVzx82U0sLvAe6FXbJAuYqz+nWKQ2Nd32e6Ev8+3H+ocv2tfBdnw9ldOtHKw90NxPU= X-Received: by 2002:ac2:5a01:: with SMTP id q1mr7585707lfn.182.1593375369728; Sun, 28 Jun 2020 13:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4703:0:0:0:0:0 with HTTP; Sun, 28 Jun 2020 13:16:08 -0700 (PDT) Reply-To: dwilde1@gmail.com In-Reply-To: References: <20200625000410.GA10210@eureka.lemis.com> <20200625025248.GB10210@eureka.lemis.com> <20200626102331.GA6406@server.rulingia.com> <1140215402.1.1593187896838@localhost> From: Donald Wilde Date: Sun, 28 Jun 2020 13:16:08 -0700 Message-ID: Subject: Re: swap space issues To: freebsd-stable , ericbsd X-Rspamd-Queue-Id: 49w2242Z1Yz3Y2l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Vewr3HaY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.19 / 15.00]; HAS_REPLYTO(0.00)[dwilde1@gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; HAS_ATTACHMENT(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.27)[-0.268]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.956]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 20:16:13 -0000 [trimming the direct cc:s] On 6/28/20, Donald Wilde wrote: > On 6/28/20, Donald Wilde wrote: >> On 6/27/20, Donald Wilde wrote: >>> On 6/26/20, Ronald Klop wrote: >>>> > [snip] [snip] I should have said that this run was done with 3 and 3 in synth. > The first attached tarball was an earlier run that failed (not > crashed) on cmake. I resolved that one through a direct build, but I > did do a graceful stoppage of synth while llvm80 was in process. It > did finally crash anyway, which led me to throttle back to 1 and 1. > > The second one, hopefully, contains every log up to the one that > crashed and hopefully also the beginning of that task. As I say, ONE > builder and ONE task, after a reboot. LLVM80 was the only builder > input. Okay, here's the summary, updated just before the crash. Attached is the full JSON, but I'll give the highlights here: { [snip] ,"elapsed":"04:43:47" ... almost five hours [snip] ,"swapinfo":" 1.6%" ... no warning! ,"load":" 1.12" ... 1 builder and 1 task } ,"builders":[ { [snip] ,"origin":"devel/llvm80" ,"lines":"15326" FWIW, that's a lot of "lines," compared to other ports. What does "lines" count? Will look it up. } ] } I'll keep examining the entire /var/log/synth archive, which I attached to my last post in this thread. :D -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Sun Jun 28 22:33:41 2020 Return-Path: Delivered-To: freebsd-stable@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 2620B3578CD for ; Sun, 28 Jun 2020 22:33:41 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49w54h2bKGz3y1K; Sun, 28 Jun 2020 22:33:40 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-lj1-x233.google.com with SMTP id h19so15942719ljg.13; Sun, 28 Jun 2020 15:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=8sUH9EpuvagME0U0Xt1JLAjLi3gm9DLhr1VYbXnWJ1s=; b=VGR68sG60Aq2yFXm66x1xO4Omr1KM/P/qDzCu4yoEc9JZMOYbf7EVAbIAEhbKOM5WC cKEs6FN/ENyRlwbut1niONhTU4BF+v+4QgZz/ds5MQvB1ASnzDAByrYK6kK7vA1ICsWx BmJUIzPgdone1fyo6wQJZPiNf23hA+o33HHoT7kn41xV84yHs1clWFVkwGet9wDZLJeX HZeCWWkrh76B1J45tY8f1NqklPBLna3tbjLvB2cbzVJmiVduonOXvVsyg1xiNqVXMGSw N/nRtcanUzQdlhNQThq+hCsqLq8ClUeBX8JgBSAvm18ekW5xMlJz4pQhltoSdZ5NMpgU FHOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=8sUH9EpuvagME0U0Xt1JLAjLi3gm9DLhr1VYbXnWJ1s=; b=njQt/fTb4gqgGrTW0fQPfHP+w+P2vNNkga/6ja/9sLg55rSG8jhlbagyq81ryx5LPp zfOSsKEn9edtikmpg03wY3gerlabPEAxBXReYslzctXy5rkQCmBYzG1+CAsS0rB+J9UN eXP2URtovXLH5ZsBi+iq1gJ6m2Jq6mVFQSHBabn3XoAaEiw61n6IuY5iPlKrzNwyi/Oq 8OhwCOIaualL4DsbFXM4fqXcoS05RaQBEM3T56DhAheXmAMcPsqZMfCGiwr6h3cVXKJ1 z/2IeNJvXW5u3lSdYk0gufJQLVXw3yRTKB3bqaSUFZua0XQXr5kevH6QM4CQw74RjDg0 xmWg== X-Gm-Message-State: AOAM533xjai+tGkl/iKc9iM0Nky8dKYN8w3ZXfv3luSJ4Rkr+pwdXWhv A6H9+S0OVte6SG5u8BmrFIBA59M2Ym7v7wY1Vd1HVPfM X-Google-Smtp-Source: ABdhPJxQcItXr3a0/SJfSL7YrR82FDp1np5zsuFRh9224ZclX9lbbuwecGIf557DrtKFT1+DxoEWB+KEfeb+dlKKDL4= X-Received: by 2002:a2e:b6cc:: with SMTP id m12mr4699386ljo.330.1593383617013; Sun, 28 Jun 2020 15:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4703:0:0:0:0:0 with HTTP; Sun, 28 Jun 2020 15:33:36 -0700 (PDT) Reply-To: dwilde1@gmail.com In-Reply-To: References: <20200625000410.GA10210@eureka.lemis.com> <20200625025248.GB10210@eureka.lemis.com> <20200626102331.GA6406@server.rulingia.com> <1140215402.1.1593187896838@localhost> From: Donald Wilde Date: Sun, 28 Jun 2020 15:33:36 -0700 Message-ID: Subject: Re: swap space issues To: ericbsd , brooks , freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49w54h2bKGz3y1K X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=VGR68sG6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.45 / 15.00]; HAS_REPLYTO(0.00)[dwilde1@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.97)[-0.965]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-0.89)[-0.894]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::233:from]; NEURAL_HAM_SHORT(-0.59)[-0.590]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 22:33:41 -0000 On 6/28/20, Donald Wilde wrote: > Okay, the post with the attachments was too big, so I canceled it. The > direct copies went out with the archives. > > Here's the one pertinent log file. I'm still examining it. > [snip] Even the log file is too big. Sent the whole thing to the LLVM80 maintainer and the Synth maintainer. >> I'll keep examining the entire /var/log/synth archive, which I >> attached to my last post in this thread. :D > > This one will again be bounced by -stable, but hopefully Eric, the > Synth maintainer will see it. > > ... and Brooks (Jason?), the llvm80 maintainer. Will repost to -stable > without attachments, and with more analysis. [snip] From the log file for devel/llvm80: [4911/4933] : && /usr/local/bin/cmake -E rm -f lib/libgtest_main.a && /usr/local/bin/ar qc lib/libgtest_main.a utils/unittest/UnitTestMain/CMakeFiles/gtest_main.dir/TestMain.cpp.o && /usr/local/bin/ranlib lib/libgtest_main.a && : [4912/4933] cd /construction/xports/devel/llvm80/work/.build/docs && /usr/local/bin/cmake -E make_directory /construction/xports/devel/llvm80/work/.build/docs/man && /usr/local/bin/sphinx-build-3.7 -b man -d /construction/xports/devel/llvm80/work/.build/docs/_doctrees-dsymutil-man -q /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs /construction/xports/devel/llvm80/work/.build/docs/man /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:96: WARNING: Unexpected indentation. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:94: WARNING: Inline literal start-string without end-string. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:97: WARNING: Block quote ends without a blank line; unexpected unindent. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:104: WARNING: Unexpected indentation. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:102: WARNING: Inline literal start-string without end-string. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:105: WARNING: Block quote ends without a blank line; unexpected unindent. [snip] /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:141: WARNING: Block quote ends without a blank line; unexpected unindent. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/MarkdownQuickstartTemplate.md:145: WARNING: Unexpected indentation. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/SpeculativeLoadHardening.md:32: WARNING: Unexpected indentation. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/SpeculativeLoadHardening.md:21: WARNING: Inline literal start-string without end-string. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/SpeculativeLoadHardening.md:34: WARNING: Block quote ends without a blank line; unexpected unindent. /construction/xports/devel/llvm80/work/llvm-8.0.1.src/docs/SpeculativeLoadHardening.md:39: WARNING: Unexpected indentation. These go on and on. I'll have to go back and examine the config. These reference tests of something by Google. IIRC, I enabled BROTLI and another Google package, something like 'Google Performance Tools.' -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Mon Jun 29 13:17:35 2020 Return-Path: Delivered-To: freebsd-stable@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 0AF9E34998B for ; Mon, 29 Jun 2020 13:17:35 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wShZ2f24z3XmS; Mon, 29 Jun 2020 13:17:34 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-lj1-x244.google.com with SMTP id e4so17996532ljn.4; Mon, 29 Jun 2020 06:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/5EaNkCuTD4hc8Ikfcg2RSa7qcHEAvHH8KNsoui8iao=; b=KIWuuqIzH05Kimyp0HyEjm5f2EUUY7eQaNgF8cfOx3BkYFtt04xCo31sj9pLVU6fW6 nfvuB4nnv4LyWeJPl+unqlQZ9Xvaeg5F0/4wN7paIJ1JjLmvtoEjl78P804gK1zqIUwb oHWIyKjqgbjumFhTbgW64RzGYIOVAIWI7VWPmYw12c4+JCBpv+S1OQ43JtcUSI9XdGun WKeEhdsY5+dZyhbwvRx1Tl8xGg8HigwoT0xUmZObBq/fogs3AkNG+V0o5/aflwayNsl/ js/PMOmZZPQB/56W+wYkhBX/0UBDUCA9DKpphZVkFTuqazglPpw4Ie+aZ7tJQ2j4hqxS qcTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=/5EaNkCuTD4hc8Ikfcg2RSa7qcHEAvHH8KNsoui8iao=; b=Dg8FL7h/gvT417+wnsm+Bw1Ph7hYpLTQ6BkajroDbXQrRXZTfJmYjRZm20rDLEyAJB 2yRAQQ8qe6/XF9aSvkNT7IoEaIHxRkkt1Z2uwzasZK7s+b82yI/DZ5wHfrW/ysMQw/A3 SCgJNH9yPsiVb/0l/H35bBxpmgf7+mhwtkm+d/ilLbfu738bLbTjZ0Rv/eWLi/NTU1F2 vbMSHj0W7sisbz+OcLM1uuI0HWqDQbGBXqKZY7IryGehCSeIIybhtkL4cboqst8cYgCm 9a68mYoAtEe6WgMGsLQ7QoPgJCl+y0aHIQzQVDJM+mGSBcyACKcoRLMgUJsv2iwtGR0M cqYQ== X-Gm-Message-State: AOAM533KhGfr5IHFSVl0cVrsaLJ1RFnnqtVEj1Laqf9+Ph45kzEaSsO/ s11axgInp9h9aN57W6zErT9I6jJKkwo0M+gpetc= X-Google-Smtp-Source: ABdhPJyQq+DwEZsibmuzW4qOB6VXCA+OvOdtzmbwwPM6s0PWZStP3mQe2nI6Di5RfPD2or5qRVg9X2wM/VnAwXg75Rs= X-Received: by 2002:a2e:590:: with SMTP id 138mr7946783ljf.85.1593436652656; Mon, 29 Jun 2020 06:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4703:0:0:0:0:0 with HTTP; Mon, 29 Jun 2020 06:17:31 -0700 (PDT) Reply-To: dwilde1@gmail.com In-Reply-To: References: From: Donald Wilde Date: Mon, 29 Jun 2020 06:17:31 -0700 Message-ID: Subject: Re: swap space issues To: Mark Millard Cc: freebsd-stable@freebsd.org, ericbsd , bdrewery@freebsd.org Content-Type: multipart/mixed; boundary="000000000000a789cb05a938e1c6" X-Rspamd-Queue-Id: 49wShZ2f24z3XmS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KIWuuqIz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2a00:1450:4864:20::244 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.43 / 15.00]; HAS_REPLYTO(0.00)[dwilde1@gmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.36)[-0.355]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.041]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.03)[-1.033]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::244:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:17:35 -0000 --000000000000a789cb05a938e1c6 Content-Type: text/plain; charset="UTF-8" [adding maintainers of synth and ccache] On 6/29/20, Mark Millard wrote: > Based on "small arm system" context experiments > mostly . . . > > If your console messasges do not include > messages about "swap_pager_getswapspace(...): failed", > then it is unlikely that being out of swap space > is the actual issue even when it reports: "was killed: > out of swap space" messages. For such contexts, making > the swap area bigger does not help. > It did not show those getswapspace messages. > In other words, "was killed: out of swap space" > is frequently a misnomer and not to be believed > for "why" the kill happened or what should be > done about it --without other evidence also being > present anyway. > > Other causes include: > > Sustained low free RAM (via stays-runnable processes). > A sufficiently delayed pageout. > The swap blk uma zone was exhausted. > The swap pctrie uma zone was exhausted. > > (stays-runnable processes are not swapped out > [kernel stacks are not swapped out] but do actively > compete for RAM via paging activity. In such a > context, free RAM can stay low.) > > The below material does not deal with the > the "exhausted" causes but does deal with > the other 2. > > Presuming that you are getting "was killed: out > of swap space" notices but are not getting > "swap_pager_getswapspace failed" notices and > that kern.maxswzone vs. system load has not > been adjusted in a way that leads to bad > memory tradeoffs . . . > > I recommend attempting use of, say, (from > my /etc/sysctl.conf ): > Attached is what I tried, but when I ran synth again, I got a corrupted HDD that fsck refuses to fix, whether in 1U mode or with fs mounted. It just will not SALVAGE even when I add the -y flag. What got corrupted was one of the /usr/.ccache directories, but 'ccache -C' doesn't clear it. I restored the original /etc/sysctl.conf, but I can't add packages or ports any more, so I'm afraid I'm going to have to dd if=/dev/zero the disk and reload from 12.1R and start over again. I can't even 'rm -Rf /usr/.ccache'. It says 'Directory not empty'. I don't need this system up and running, so I'm not going to make any more changes until I see if any of you have suggestions to try first. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** --000000000000a789cb05a938e1c6 Content-Type: application/octet-stream; name="sysctl.conf.new" Content-Disposition: attachment; filename="sysctl.conf.new" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 IyAkRnJlZUJTRDogc3RhYmxlLzEyL3NiaW4vc3lzY3RsL3N5c2N0bC5jb25mIDMzNzYyNCAyMDE4 LTA4LTExIDEzOjI4OjAzWiBicmQgJAojCiMgIFRoaXMgZmlsZSBpcyByZWFkIHdoZW4gZ29pbmcg dG8gbXVsdGktdXNlciBhbmQgaXRzIGNvbnRlbnRzIHBpcGVkIHRocnUKIyAgYGBzeXNjdGwnJyB0 byBhZGp1c3Qga2VybmVsIHZhbHVlcy4gIGBgbWFuIDUgc3lzY3RsLmNvbmYnJyBmb3IgZGV0YWls cy4KIwoKIyBVbmNvbW1lbnQgdGhpcyB0byBwcmV2ZW50IHVzZXJzIGZyb20gc2VlaW5nIGluZm9y bWF0aW9uIGFib3V0IHByb2Nlc3NlcyB0aGF0CiMgYXJlIGJlaW5nIHJ1biB1bmRlciBhbm90aGVy IFVJRC4KI3NlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkcz0wCnNlY3VyaXR5LmJzZC5zZWVfb3Ro ZXJfdWlkcz0wCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfZ2lkcz0wCnNlY3VyaXR5LmJzZC5zZWVf amFpbF9wcm9jPTAKCiMKIyBEZWxheSB3aGVuIHBlcnNpc3RlbnQgbG93IGZyZWUgUkFNIGxlYWRz IHRvCiMgT3V0IE9mIE1lbW9yeSBraWxsaW5nIG9mIHByb2Nlc3Nlcy4gVGhlCiMgZGVsYXkgaXMg YSBjb3VudCBvZiBrZXJuZWwtYXR0ZW1wdHMgdG8gZ2FpbgojIGZyZWUgUkFNIChzbyBub3QgdGlt ZSB1bml0cykuCiN2bS5wYWdlb3V0X29vbV9zZXE9MTIgIyBkZWZhdWx0CiN2bS5wYWdlb3V0X29v bV9zZXE9LTEgIyBpbmZpbml0ZSAobm90IHN1cmUgZXhpc3RzID8/PykKdm0ucGFnZW91dF9vb21f c2VxPTEyMAojCiMgRm9yIHBsdW50eSBvZiBzd2FwL3BhZ2luZyBzcGFjZSAod2lsbCBub3QKIyBy dW4gb3V0KSwgYXZvaWQgcGFnZW91dCBkZWxheXMgbGVhZGluZyB0bwojIE91dCBPZiBNZW1vcnkg a2lsbGluZyBvZiBwcm9jZXNzZXM6CiN2bS5wZmF1bHRfb29tX2F0dGVtcHRzPS0xICMgaW5maW5p dGUKIwojIEZvciBwb3NzaWJseSBpbnN1ZmZpY2llbnQgc3dhcC9wYWdpbmcgc3BhY2UKIyAobWln aHQgcnVuIG91dCksIGluY3JlYXNlIHRoZSBwYWdlb3V0IGRlbGF5CiMgdGhhdCBsZWFkcyB0byBP dXQgT2YgTWVtb3J5IGtpbGxpbmcgb2YKIyBwcm9jZXNzZXM6CnZtLnBmYXVsdF9vb21fYXR0ZW1w dHM9IDEwCnZtLnBmYXVsdF9vb21fd2FpdD0gMQojIChUaGUgbXVsdGlwbGljYXRpb24gaXMgdGhl IHRvdGFsIGJ1dCB0aGVyZQojIGFyZSBvdGhlciBwb3RlbnRpYWwgdHJhZG9mZnMgaW4gdGhlIGZh Y3RvcnMKIyBtdWx0aXBsaWVkIGZvciB0aGUgc2FtZSB0b3RhbC4pCgojTm90ZTogQXMgb2Ygc3Rh YmxlLzEyIC1yMzUxNzc2ICwgc3RhYmxlIGdvdAojc3VwcG9ydCBmb3Igdm0ucGZhdWx0X29vbV9h dHRlbXB0cyBhbmQKI3ZtLnZtLnBmYXVsdF9vb21fd2FpdCB2aWEgYW4gTUZDLiBTdGFibGUgaGFz CiNoYWQgc3VwcG9ydCBmb3Igdm0ucGFnZW91dF9vb21fc2VxIGZvcgojbXVjaCBsb25nZXIgdGhh biB0aGF0LgojCiNOb3RlOiBMYXJnZXIgdmFsdWVzIG9mIHZtLnBhZ2VvdXRfb29tX3NlcQojd2ls bCB3YWl0IGV2ZW4gbG9uZ2VyLiBUaGUgZGVmYXVsdCB2YWx1ZSBpcwojMTIgKGxhc3QgSSBjaGVj a2VkKS4gTm8gZmlndXJlIHR1cm5zIG9mZgojdGhlIHNwZWNpZmljIG1lY2hhbmlzbSBhcyBmYXIg YXMgSSBrbm93LgojCg== --000000000000a789cb05a938e1c6-- From owner-freebsd-stable@freebsd.org Mon Jun 29 20:20:39 2020 Return-Path: Delivered-To: freebsd-stable@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 E6A5D35403E for ; Mon, 29 Jun 2020 20:20:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 49wf4k4VyXz4LW0 for ; Mon, 29 Jun 2020 20:20:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: rOXCY2gVM1neCWmegTh4QfZnBMW90XKwzBmIJAfTFhNV3KMm9VcinWM3MJttVR5 qrszsefdDGDCfw858MOEb6ZbNbtgdQ9txv38QsxuAtgARK5AWUZ2HEVYllNud8AIEFXwPi0RSd2A vUE5dX9qH4fy.JgePTheGNUB745O8.iWskNBbiAvY5_4httFkP3KjS6XzUguDnw_.JR_C.9cUiof ybm.WEw1BknPdrr1M44A5qu.cjjYfzrR3oir2RK0XAsE3eQaXEC7qhR90WsZ502vigIx_Bm5nld7 EP.vIzOjD2rM4QSmO9Wdf65S7PtP4bOUn8RpeFem.Lq33_NAOxzwSXxrPcSvXq9QAcxSAzg_EuC2 bLzQJferF3Z93fCAYrl6YINSkXLEsJu6aGTW7yPE5vEKOuSwmsOxqejF5OaIE7fO0_IBqrF5T7ug xaqLkdJXp3Z3LpVGuOYfPsQH17GL4c22D51xHcj5i51sMIQ.ird5i_vMFZsiIu8cTwvzg5jy7d9J LRMjWMSVGcWaMVwpeGsxuHtprx1VSebWJKQFAdKj6Z3ebMcDrsrRVU56.sP33wI1uQVwWXt.k2fG 4yNsyTPMvjO9vWfTxEqCPNXPxmTqmTF3XOolgTdc2KiOTLxALiTpL44a49BBIhETDGKJriPKxla3 D9Az6IZldrcCN7dPbcHcY7hPB2tlEsd04in1nxKG0zVj_HccUYVipcnf6GQm..01VjJ0H3sm9mov 31sD.FbsNgaWq6RUbKc8z8KcS28q.D3kGlRgMXKLWIdRUGDJdeAdjqT02PPJX27DvkOtDroWsaZW 7bi5SfYDFDdAtgBJ9bIx8c1qHetijASEUS8XJpTZyn1mIHDYtvLvG6eXFljnk4FwktvpUdmghSjC Hs9WJLiNHdawa8qMv2eh1AShKLokogY.zmZR.zuX9nf2TczxxyO3ga4c5iwMOg7eIoBsa2gz8Njo QYwkig65v_XobChh5n6kNxdyHIp1.taiUbU1GXd.Caq67OBYxXDIPXBg.VA43lVoInGiNlkfbOFN wpHxdSIqqQBX6AF7CRIScSHf157TC3oaxrAGk.WsnxECjgMiEy90nE65kXqmvBVg4lJiBsvVrbm5 L0Yj7_SoTS1W8nOs1BX50NX15j6H.hYnvSo6dfebDSa7wzM6IX31cpT7zJwSq6MWaOnp0SvBDHdw I8C2Eg8C9MP1wXC2UAi14Xi_36FF_58f9rZQYtG9ERNycGIBgcnNXKx5CQcRfroWJMVCTKY.BGSx 4FnFL5yIPDB7ofrmSzVHo9OqMWV1oHNrVuy2BQvfCNdk_rcRaY.FdxF49._BpnbA5Ah1Bz4ls1M3 qyZpW1aOfN4ALKWZ3jZTSHJUW.krk.B2t6F4HxLuUkyOFdaxk43yM.prSoOlboPIcli7O7F051ak nrptWBkkyTYC.oqq4rzTAj0.1qQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jun 2020 20:20:36 +0000 Received: by smtp429.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b164c7835c0c9d196e2850e92a893960; Mon, 29 Jun 2020 20:20:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: swap space issues From: Mark Millard In-Reply-To: Date: Mon, 29 Jun 2020 13:20:33 -0700 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D0E1E39-2607-4D62-A232-F39C6BE1CC0D@yahoo.com> References: To: dwilde1@gmail.com X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49wf4k4VyXz4LW0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.75 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.20)[-1.204]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.047]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.002]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 20:20:40 -0000 [I'm now subscribed so my messages should go through to the list.] On 2020-Jun-29, at 06:17, Donald Wilde wrote: > [adding maintainers of synth and ccache] >=20 > On 6/29/20, Mark Millard wrote: >> Based on "small arm system" context experiments >> mostly . . . >>=20 >> If your console messasges do not include >> messages about "swap_pager_getswapspace(...): failed", >> then it is unlikely that being out of swap space >> is the actual issue even when it reports: "was killed: >> out of swap space" messages. For such contexts, making >> the swap area bigger does not help. >>=20 >=20 > It did not show those getswapspace messages. Any other potentially of interest console messages? >> In other words, "was killed: out of swap space" >> is frequently a misnomer and not to be believed >> for "why" the kill happened or what should be >> done about it --without other evidence also being >> present anyway. >>=20 >> Other causes include: >>=20 >> Sustained low free RAM (via stays-runnable processes). >> A sufficiently delayed pageout. >> The swap blk uma zone was exhausted. >> The swap pctrie uma zone was exhausted. >>=20 >> (stays-runnable processes are not swapped out >> [kernel stacks are not swapped out] but do actively >> compete for RAM via paging activity. In such a >> context, free RAM can stay low.) >>=20 >> The below material does not deal with the >> the "exhausted" causes but does deal with >> the other 2. >>=20 >> Presuming that you are getting "was killed: out >> of swap space" notices but are not getting >> "swap_pager_getswapspace failed" notices and >> that kern.maxswzone vs. system load has not >> been adjusted in a way that leads to bad >> memory tradeoffs . . . >>=20 >> I recommend attempting use of, say, (from >> my /etc/sysctl.conf ): >>=20 > Attached is what I tried, but when I ran synth again, I got a > corrupted HDD that fsck refuses to fix, whether in 1U mode or with fs > mounted. It just will not SALVAGE even when I add the -y flag. That is a horrible result. I assume that you rebooted after editing sysctl.conf or manually applied the values separately instead. What sort of console messages were generated? Was the corruption the only issue? Did the system crash? In what way? Your notes on what you set have a incorrect comment about a case that you did not use: # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: #vm.pfault_oom_attempts=3D-1 # infinite vm.pfault_oom_attempts being -1 is a special value that disables the the logic for the vm.pfault_oom_attempts and vm.pfault_oom_wait pair: Willing to wait indefinitely relative to how long the pageout takes, no retries. (Other OOM criteria may still be active.) You report using: # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: vm.pfault_oom_attempts=3D 10 vm.pfault_oom_wait=3D 1 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied for the same total.) Note: kib might be interested in what happens for, say, 10 and 1, 5 and 2, and 1 and 10. He has asked for such before from someone having OOM problems but, to my knowledge, no one has taken him up on such testing. (He might be only after 10/1 and 1/10 or other specific figures. Best to ask him if you want to try such things for him.) I've always set up to use vm.pfault_oom_attempts=3D-1 (avoiding running out of swap space by how I configure things and what I choose to run). I avoid things like tempfs that compete for RAM, especially in low memory contexts. For 64-bit environments I've never had to have enough swapspace that the boot reported an issue for kern.maxswapzone : more swap is allowed for the same amount of RAM as is allowed for a 32-bit environment. In the 64-bit type of context with 1 GiByte+ of RAM I do -j4 build world buildkernel, 3072 MiBytes of swap. For 2 GiByte+ of RAM I use 4 poudriere builders (one per core), each allowed 4 processes (ALLOW_MAKE_JOBS=3Dyes), so the load average can at times reach around 16 over significant periods. I also use USB SSDs instead of spinning rust. The port builds include a couple of llvm's and other toolchains. But there could be other stuff around that would not fit. (So synth for you vs. poudriere for me is a difference in our contexts. ALso, I stick to default kern.maxswapzone use without boot messages about exceeding the maximum recommended amount. Increasing kern.maxswapzone trades off KVM available for other purposes and I avoid the tradeoffs that I do not understand.) For 32-bit environments with environments with 2 GiByte+ of RAM I have to be more careful to be sure of avoiding running out of swap for what I do. PARALLEL_JOBS=3D2 and ALLOW_MAKE_JOBS=3Dyes for poudruere (so load average around 8 over some periods). -j4 for buildworld buildkernel . For 32-bit 1 GiByte I used -j2 for buildworld buildkernel , 1800 MiBytes of swap. As I remember, I used MAKE_JOBS_NUMBER_LIMIT=3D2 and PARALLEL_JOBS=3D2 for port building with poudriere. (It has been a while.) (My context is head, not stable.) For reference: # sysctl -d vm.pfault_oom_wait vm.pfault_oom_wait: Number of seconds to wait for free pages before = retrying the page fault handler # sysctl -d vm.pfault_oom_attempts vm.pfault_oom_attempts: Number of page allocation attempts in page fault = handler before it triggers OOM handling # sysctl -d vm.pageout_oom_seq vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM (You reported using vm.pageout_oom_seq=3D120 like I use.) > What got corrupted was one of the /usr/.ccache directories, but > 'ccache -C' doesn't clear it. I've not used ccache. So that is another variation in our contexts. I use UFS, not ZFS. I avoid tmpfs and such that complete for memory. > I restored the original /etc/sysctl.conf, but I can't add packages or > ports any more, so I'm afraid I'm going to have to dd if=3D/dev/zero = the > disk and reload from 12.1R and start over again. The corruption itself might be of interest to some system folks if it is reproducible, depending on how things got that way (crash/panic?). > I can't even 'rm -Rf /usr/.ccache'. It says 'Directory not empty'. >=20 > I don't need this system up and running, so I'm not going to make any > more changes until I see if any of you have suggestions to try first. Note: Below I include the part of my original full message that did not make it to the list: >> . . . >>=20 >> # >> # Delay when persistent low free RAM leads to >> # Out Of Memory killing of processes. The >> # delay is a count of kernel-attempts to gain >> # free RAM (so not time units). >> vm.pageout_oom_seq=3D120 >> # >> # For plunty of swap/paging space (will not >> # run out), avoid pageout delays leading to >> # Out Of Memory killing of processes: >> vm.pfault_oom_attempts=3D-1 >> # >> # For possibly insufficient swap/paging space >> # (might run out), increase the pageout delay >> # that leads to Out Of Memory killing of >> # processes: >> #vm.pfault_oom_attempts=3D 10 >> #vm.pfault_oom_wait=3D ??? >> # (The multiplication is the total but there >> # are other potential tradoffs in the factors >> # multiplied for the same total.) >>=20 >> Note: As of stable/12 -r351776 , stable got >> support for vm.pfault_oom_attempts and >> vm.vm.pfault_oom_wait via an MFC. Stable has >> had support for vm.pageout_oom_seq for >> much longer than that. >>=20 >> Note: Larger values of vm.pageout_oom_seq >> will wait even longer. The default value is >> 12 (last I checked). No figure turns off >> the specific mechanism as far as I know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Jun 29 21:12:48 2020 Return-Path: Delivered-To: freebsd-stable@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 C633C355576 for ; Mon, 29 Jun 2020 21:12:48 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wgDw1kfVz4R7w for ; Mon, 29 Jun 2020 21:12:48 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-lf1-x144.google.com with SMTP id g139so10016784lfd.10 for ; Mon, 29 Jun 2020 14:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DwJKkABAAUbbFPdOuXcp+R1VEV/G0DxoNZh9yA5TZuQ=; b=NWJO6n9JkjEXTff1Bwpk+LqKJyVicpEwltg5XQmpvI1ApRtLiXJlVZ9fLkYkmI34BB yRVrrMbc+f5SHE0GMXtcDpPy3t6/ynUFGW6SZEYucxaxnKCCYeuuVwqqneAx2ABmSGqy pM139FTxSytB4pAyHM7o0CWuBMZG9/gEKFxdS7EufubonAzvDEyY3YaKPpbM56xrQluU WrcW6bILr9ijQhsYI3SB0JUQEcAn6GK4+CScanLP8y/+YdEY/MPr0F6qVF8ShBi8wbcm z0padWGgTW0iTiWwEk7eJ6jQZFt9hIZDbFYENbaW6JaVG5GsjcryRYwdU8YANB7mz85O mhDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=DwJKkABAAUbbFPdOuXcp+R1VEV/G0DxoNZh9yA5TZuQ=; b=dh8c/lIi4zAQGtceWXLxlV123TknA1N4En5owT1oz4j+gaA6PDZ+k5w+OxuCJSqCFq jxg9dEUTSGO3JswT0TM7VGRTloGnOAm9c2Y2pxYnRIn2Cq6HaYP7+ajGT442BSOboTXU AuEt+N85gAMswdTU3mg4cBCcLNjFvT/JL4xCuGstS/yQcN2bm24UoUcDa0yM2cv9Z7E/ cpDKuoOmXA08NfxVM39oxYC2IO88QlZulcRCNPx7FC/nGdIG4QQIWb5Nor9xISJfxE4L GgoIc3/mS0yAGomiPAwCGCMkEBIOJMCCC4SzilvH00Q9jIJ4K8buWGlabUKdx9NlKQs/ 8qNQ== X-Gm-Message-State: AOAM531hsUuD9xWuT+x3RnQOE6vXkCnZFYMsS8to9RqR/gDzvyc6qj+h tSeciOjDzKEl3jYJIYLXgnfd7f18DPg0Wp4PKFY= X-Google-Smtp-Source: ABdhPJzd+vhoRY0Yv7J/Qmq0ATIo3MHo/cAIQ6ha0TvNjh3pUNoBSPBKvsr5FYx8T8FqTu52X440OzzlZPRWG9MMxQs= X-Received: by 2002:ac2:52af:: with SMTP id r15mr10313974lfm.24.1593465165322; Mon, 29 Jun 2020 14:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4703:0:0:0:0:0 with HTTP; Mon, 29 Jun 2020 14:12:44 -0700 (PDT) Reply-To: dwilde1@gmail.com In-Reply-To: <2D0E1E39-2607-4D62-A232-F39C6BE1CC0D@yahoo.com> References: <2D0E1E39-2607-4D62-A232-F39C6BE1CC0D@yahoo.com> From: Donald Wilde Date: Mon, 29 Jun 2020 14:12:44 -0700 Message-ID: Subject: Re: swap space issues To: Mark Millard Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49wgDw1kfVz4R7w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=NWJO6n9J; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2a00:1450:4864:20::144 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.33 / 15.00]; HAS_REPLYTO(0.00)[dwilde1@gmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.26)[-0.259]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.045]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.024]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::144:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:12:48 -0000 On 6/29/20, Mark Millard wrote: > [I'm now subscribed so my messages should go through to > the list.] > > On 2020-Jun-29, at 06:17, Donald Wilde wrote: > >> [adding maintainers of synth and ccache] >> >> On 6/29/20, Mark Millard wrote: >>> Based on "small arm system" context experiments >>> mostly . . . >>> >>> If your console messasges do not include >>> messages about "swap_pager_getswapspace(...): failed", >>> then it is unlikely that being out of swap space >>> is the actual issue even when it reports: "was killed: >>> out of swap space" messages. For such contexts, making >>> the swap area bigger does not help. >>> >> >> It did not show those getswapspace messages. > > Any other potentially of interest console messages? > >>> In other words, "was killed: out of swap space" >>> is frequently a misnomer and not to be believed >>> for "why" the kill happened or what should be >>> done about it --without other evidence also being >>> present anyway. >>> >>> Other causes include: >>> >>> Sustained low free RAM (via stays-runnable processes). >>> A sufficiently delayed pageout. >>> The swap blk uma zone was exhausted. >>> The swap pctrie uma zone was exhausted. >>> >>> (stays-runnable processes are not swapped out >>> [kernel stacks are not swapped out] but do actively >>> compete for RAM via paging activity. In such a >>> context, free RAM can stay low.) >>> >>> The below material does not deal with the >>> the "exhausted" causes but does deal with >>> the other 2. >>> >>> Presuming that you are getting "was killed: out >>> of swap space" notices but are not getting >>> "swap_pager_getswapspace failed" notices and >>> that kern.maxswzone vs. system load has not >>> been adjusted in a way that leads to bad >>> memory tradeoffs . . . >>> >>> I recommend attempting use of, say, (from >>> my /etc/sysctl.conf ): >>> >> Attached is what I tried, but when I ran synth again, I got a >> corrupted HDD that fsck refuses to fix, whether in 1U mode or with fs >> mounted. It just will not SALVAGE even when I add the -y flag. > > That is a horrible result. > > I assume that you rebooted after editing Yes. > sysctl.conf or manually applied the > values separately instead. > > What sort of console messages were generated? > Was the corruption the only issue? Did the system > crash? In what way? The symptoms used to be that, once synth crashed by OOM, it would refuse to allow any packages to be added, because the synth data structures were blasted. Synth is unfortunately pretty blockheaded in that you can't control the order of the ports built. You can control how many ports get built at a time and how many tasks per port get started and managed. As I say, though, this change led to -- I won't say _caused_ -- a corruption of the disk area used for ccache. I could not recover from that, although I could have turned ccache off. I was able to manually build llvm80 from the ports, so the dependency gotcha that gave me the issues was in some other dependency. As I said in my other message, it seems to be the Google performance tools or Brotli that might have been broken. What's great, Mark, is that you've given me a lot more insight into the tunability of the kernel. As I said, I do a lot of IoT and embedded work with ARM-based Micro-Controllers. > > Your notes on what you set have a incorrect > comment about a case that you did not use: > > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > #vm.pfault_oom_attempts=-1 # infinite > > vm.pfault_oom_attempts being -1 is a special > value that disables the the logic for the > vm.pfault_oom_attempts and vm.pfault_oom_wait > pair: Willing to wait indefinitely relative to > how long the pageout takes, no retries. (Other > OOM criteria may still be active.) Ah, I appreciate the distinction. :) > > You report using: > > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes: > vm.pfault_oom_attempts= 10 > vm.pfault_oom_wait= 1 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied for the same total.) > > Note: kib might be interested in what happens > for, say, 10 and 1, 5 and 2, and 1 and 10. > He has asked for such before from someone > having OOM problems but, to my knowledge, > no one has taken him up on such testing. > (He might be only after 10/1 and 1/10 or > other specific figures. Best to ask him if > you want to try such things for him.) Who is 'kib'? I'm still learning the current team of the Project. > > I've always set up to use vm.pfault_oom_attempts=-1 > (avoiding running out of swap space by how I > configure things and what I choose to run). I > avoid things like tempfs that compete for RAM, > especially in low memory contexts. Until you explained what you have taught me, I thought these were swap-related issues. TBH, I am getting disgusted with Synth, as good as it (by spec, not actuality) is supposed to be. CCache I've used for years, and never had this kind of issue. > > For 64-bit environments I've never had to have > enough swapspace that the boot reported an issue > for kern.maxswapzone : more swap is allowed for > the same amount of RAM as is allowed for a 32-bit > environment. Now that you've opened the possibility, it would explain how it goes from <3% swap use to OOM in moments... it's not a swap usage issue! That's an important thing to learn. Not having heard from anyone else, I'm in the process of zeroing my drive and starting over. > > In the 64-bit type of context with 1 GiByte+ > of RAM I do -j4 build world buildkernel, 3072 MiBytes > of swap. For 2 GiByte+ of RAM I use 4 poudriere builders > (one per core), each allowed 4 processes > (ALLOW_MAKE_JOBS=yes), so the load average can at times > reach around 16 over significant periods. I also use > USB SSDs instead of spinning rust. The port builds > include a couple of llvm's and other toolchains. But > there could be other stuff around that would not fit. > > (So synth for you vs. poudriere for me is a > difference in our contexts. ALso, I stick to > default kern.maxswapzone use without boot > messages about exceeding the maximum > recommended amount. Increasing kern.maxswapzone > trades off KVM available for other purposes and > I avoid the tradeoffs that I do not understand.) [snip] > (My context is head, not stable.) Thanks for documenting your usage. I'll store a pointer to this week's -stable archives so I can come back to this when I get to smaller builds. > > For reference: > > # sysctl -d vm.pfault_oom_wait > vm.pfault_oom_wait: Number of seconds to wait for free pages before retrying > the page fault handler > > # sysctl -d vm.pfault_oom_attempts > vm.pfault_oom_attempts: Number of page allocation attempts in page fault > handler before it triggers OOM handling > > # sysctl -d vm.pageout_oom_seq > vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM > > (You reported using vm.pageout_oom_seq=120 > like I use.) > >> What got corrupted was one of the /usr/.ccache directories, but >> 'ccache -C' doesn't clear it. > > I've not used ccache. So that is another variation > in our contexts. > > I use UFS, not ZFS. I avoid tmpfs and such that complete > for memory. I'm using UFS on MBR partitions. > > >> I restored the original /etc/sysctl.conf, but I can't add packages or >> ports any more, so I'm afraid I'm going to have to dd if=/dev/zero the >> disk and reload from 12.1R and start over again. > > The corruption itself might be of interest to > some system folks if it is reproducible, depending > on how things got that way (crash/panic?). > >> I can't even 'rm -Rf /usr/.ccache'. It says 'Directory not empty'. >> >> I don't need this system up and running, so I'm not going to make any >> more changes until I see if any of you have suggestions to try first. > > Note: Below I include the part of my original full message > that did not make it to the list: > >>> . . . >>> >>> # >>> # Delay when persistent low free RAM leads to >>> # Out Of Memory killing of processes. The >>> # delay is a count of kernel-attempts to gain >>> # free RAM (so not time units). >>> vm.pageout_oom_seq=120 >>> # >>> # For plunty of swap/paging space (will not >>> # run out), avoid pageout delays leading to >>> # Out Of Memory killing of processes: >>> vm.pfault_oom_attempts=-1 >>> # >>> # For possibly insufficient swap/paging space >>> # (might run out), increase the pageout delay >>> # that leads to Out Of Memory killing of >>> # processes: >>> #vm.pfault_oom_attempts= 10 >>> #vm.pfault_oom_wait= ??? >>> # (The multiplication is the total but there >>> # are other potential tradoffs in the factors >>> # multiplied for the same total.) >>> >>> Note: As of stable/12 -r351776 , stable got >>> support for vm.pfault_oom_attempts and >>> vm.vm.pfault_oom_wait via an MFC. Stable has >>> had support for vm.pageout_oom_seq for >>> much longer than that. >>> >>> Note: Larger values of vm.pageout_oom_seq >>> will wait even longer. The default value is >>> 12 (last I checked). No figure turns off >>> the specific mechanism as far as I know. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Mon Jun 29 22:22:29 2020 Return-Path: Delivered-To: freebsd-stable@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 4EBFD3565FD for ; Mon, 29 Jun 2020 22:22:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 49whnJ1HJPz4XGl for ; Mon, 29 Jun 2020 22:22:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: J4FMALQVM1mtJMHpKBifrQ4BXJQMVLrLO.VUbEwL0yEn2vVza_2uT6T9ggBnvkE Bzv1bvAy0ePW1FJMpoEhFDtjw.zO5rf15fHIPGCTpwCqiJY1thL92DQ5Hhw8cuXzLtVqMbaxlFvP jyW0gf1rIq2rxxyltWqKxkat28o3w.b7t2RENRyNOt9Fr2pa9oI8v.5k0aeHxZ3nDcBcM0BCIOjo EsCvxIW_cJQ87mJC3W6bwngOVAe7Svp0igigZt6JsImpWNEzie3U6jGAD7CWJMFGc_I9WL3vNJBj uWKYr6nVTovfFhX_imuSCp3z4_DzE5TTEmn4jDgdMta96DXLxzXpWw7wgeJFLEidRxe7ytDxuzxk cTGfTJRj5aC5MVOLBZgH38K4eTXFEu2OAusc7McGtXhZePAeNR8pTLHYVbRV2jvQiUgjAf_0yAIs oWivaLGcqpTIGtVzP6HiUIm.oAI6fjIHjSVJZ49rZg9KLXGCqug2FbymQv2uGy7zXNvmsaA03H8W cd6zHx9Qv7ebwFcpwtBdzlq2Q6C7uL4tQF2G5WojEc7SVkauXe0y2s7JyhIu7htJCQya8nDzCKBa .TsrVDbOg7F.e_7.7JmibkTVZ7YaFAJPDIlCCpSh.07739ocbVmfY9Z8T1vpEGNK86qW_RAwO5o3 yGe1hhTEMTg41KcEU14LXU0sPRq9MP1E2se.Ax2kLt2ORLcwE2VBN5Ceb7hMjbG.SFA.SYrjCOU. N0344GB9Cmio7TbVy37LppAZQSuy8DQXzdgEqCXq5HajG3Uzdd9qj13y7mvB1lJf6hdZ7ea2jqk9 fw_C.2yGxKKlC__8.gsgVqvQ6El.WJr3UfT3kWA1x48snP7umqdchigZE9FYPW.chtqmVRYPNNQH a1oBmBqwZJjylcrjMElBgYKabf_SSv36iJvbA5Rn9FXoiEnYP6viNLDk0.DNDztIUykt7p39Y47y yjoj_w5eNGtUYvQ267Wdo2Um7w3dTWB51JTiXXnsI_UuXiT31p_EYUJZzirAY5LPWA04NwFbFCIh riZtZiZvqJ07xU4RbJ8O_xyelx47_gsIObvL.wqFrsQXTjNIGnEo4nxwFlEjxuVl9pTOzEt6M6e9 uqe_qqdUkPsYTRtyQPW.dtvuA8ZoOFeEthfwvhBDX0hlz2k6jyiBMj4fOL0WQULJXyUgMBGp2bdB hlvPPkPZ7OQzLgm5FR_nNr_J.6Y4FFaY8sw3QxjDzpxMGMWVn5BJXck_.4FELoiDYWyBgHvaIoUA Ye16dRJwLJ6Pqhq988g68rOirP6Ekq8CJm8jBLZrRoSOLMAm3zXw0Q90yxIzHLp2WU2cjjwv9VJ6 MfbtOqtZNsdARDlEylvdpCIKqB91qMbLOkVP4rUkhjOytuINk0vZaFikvfjM7L3kk6D5qc1STh13 EehegZcjHOMO6trU4CljIwy_Z Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jun 2020 22:22:25 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 450f74c78e7d703697c09ac0c5dfa63a; Mon, 29 Jun 2020 22:22:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: swap space issues From: Mark Millard In-Reply-To: Date: Mon, 29 Jun 2020 15:22:22 -0700 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <13D7C246-9842-4DFA-92EB-7161F52ED39E@yahoo.com> References: <2D0E1E39-2607-4D62-A232-F39C6BE1CC0D@yahoo.com> To: dwilde1@gmail.com X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49whnJ1HJPz4XGl X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.66 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.11)[-0.110]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.002]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 22:22:29 -0000 On 2020-Jun-29, at 14:12, Donald Wilde wrote: > On 6/29/20, Mark Millard wrote: >> [I'm now subscribed so my messages should go through to >> the list.] >> >> On 2020-Jun-29, at 06:17, Donald Wilde wrote: >> >>> . . . >> >> You report using: >> >> # For possibly insufficient swap/paging space >> # (might run out), increase the pageout delay >> # that leads to Out Of Memory killing of >> # processes: >> vm.pfault_oom_attempts= 10 >> vm.pfault_oom_wait= 1 >> # (The multiplication is the total but there >> # are other potential tradoffs in the factors >> # multiplied for the same total.) >> >> Note: kib might be interested in what happens >> for, say, 10 and 1, 5 and 2, and 1 and 10. >> He has asked for such before from someone >> having OOM problems but, to my knowledge, >> no one has taken him up on such testing. >> (He might be only after 10/1 and 1/10 or >> other specific figures. Best to ask him if >> you want to try such things for him.) > > Who is 'kib'? I'm still learning the current team of the Project. Konstantin Belousov Also known as kib (from kib at freebsd.org). Also known as kostik (from part of his gmail address?). >> I've always set up to use vm.pfault_oom_attempts=-1 >> (avoiding running out of swap space by how I >> configure things and what I choose to run). I >> avoid things like tempfs that compete for RAM, >> especially in low memory contexts. > > Until you explained what you have taught me, I thought these were > swap-related issues. > > TBH, I am getting disgusted with Synth, as good as it (by spec, not > actuality) is supposed to be. While I experimented with Synth a little a long time ago, I normally stick to tools and techniques that work across amd64, powerpc64, aarch64, 32-bit powerpc, and armv7 when I can. So, the experiment was strictly temporary on one environment at the time. > CCache I've used for years, and never had this kind of issue. >> >> For 64-bit environments I've never had to have >> enough swapspace that the boot reported an issue >> for kern.maxswapzone : more swap is allowed for >> the same amount of RAM as is allowed for a 32-bit >> environment. > > Now that you've opened the possibility, it would explain how it goes > from <3% swap use to OOM in moments... it's not a swap usage issue! > That's an important thing to learn. > > Not having heard from anyone else, I'm in the process of zeroing my > drive and starting over. >> >> In the 64-bit type of context with 1 GiByte+ >> of RAM I do -j4 build world buildkernel, 3072 MiBytes >> of swap. For 2 GiByte+ of RAM I use 4 poudriere builders >> (one per core), each allowed 4 processes >> (ALLOW_MAKE_JOBS=yes), so the load average can at times >> reach around 16 over significant periods. I also use >> USB SSDs instead of spinning rust. The port builds >> include a couple of llvm's and other toolchains. But >> there could be other stuff around that would not fit. >> >> (So synth for you vs. poudriere for me is a >> difference in our contexts. ALso, I stick to >> default kern.maxswapzone use without boot >> messages about exceeding the maximum >> recommended amount. Increasing kern.maxswapzone >> trades off KVM available for other purposes and >> I avoid the tradeoffs that I do not understand.) > [snip] >> (My context is head, not stable.) > > Thanks for documenting your usage. I'll store a pointer to this week's > -stable archives so I can come back to this when I get to smaller > builds. >> >> . . . >> >>> What got corrupted was one of the /usr/.ccache directories, but >>> 'ccache -C' doesn't clear it. >> >> I've not used ccache. So that is another variation >> in our contexts. >> >> I use UFS, not ZFS. I avoid tmpfs and such that complete >> for memory. > > I'm using UFS on MBR partitions. GPT for root file systems for me, other than any old PowerMacs (APM). (On the small arm's I just use microsd cards to get to booting the root file system on a GPT based USB SSD via a technique that works the same for all such arms that I sometimes have access to, other than the RPi4's at this stage.) >> . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Tue Jun 30 08:40:00 2020 Return-Path: Delivered-To: freebsd-stable@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 11D5D36274F for ; Tue, 30 Jun 2020 08:40:00 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wyTp5QJnz464q for ; Tue, 30 Jun 2020 08:39:58 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 05U8dgxG062771 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jun 2020 18:39:48 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 05U8daUY069917 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2020 18:39:36 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 05U8daNq069916; Tue, 30 Jun 2020 18:39:36 +1000 (AEST) (envelope-from peter) Date: Tue, 30 Jun 2020 18:39:36 +1000 From: Peter Jeremy To: Donald Wilde Cc: freebsd-stable Subject: Re: swap space issues Message-ID: <20200630083936.GA63105@server.rulingia.com> References: <20200625025248.GB10210@eureka.lemis.com> <20200626102331.GA6406@server.rulingia.com> <1140215402.1.1593187896838@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 49wyTp5QJnz464q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-4.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.018]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; NEURAL_SPAM_SHORT(0.03)[0.027]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:40:00 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jun-28 12:33:21 -0700, Donald Wilde wrote: >On 6/28/20, Donald Wilde wrote: >> On 6/27/20, Donald Wilde wrote: >>> 'spinning rust' for a disk. My loader.conf has >>> kern.maxswzone=3D4200000 and ccache is fully active and working for both >>> root on tcsh and users on sh. Based on my calculations, that maxswzone is good for just under 1GB swap. What do you see have for vm.swap_maxpages and vm.swzone? >> Synth is still crashing hard, same issue. >An update. Synth still crashed with one swap zone of 16GB. What do you mean by "swap zone"? Do you mean you have one 16GB swap device? >stack overflow. As I say, there was no warning. Everything was fine, >then memory usage went through the roof! I've just tried building llvm80 via ports[1] on my laptop, using the same options as you. I have 4GB RAM and 4GB swap with system defaults and had no problems with an 8-way build. The highest swap usage I noticed was <500MB. I suspect your problems are related to either ccache or synth. >The second one, hopefully, contains every log up to the one that >crashed and hopefully also the beginning of that task. As I say, ONE >builder and ONE task, after a reboot. LLVM80 was the only builder >input. "one builder and one task" - these are presumably synth terms since they aren't standard ports building terms. You should be able to do a single-theaded build of llvm80 in 4GB RAM without problems. That said, I notice that the first log file suggests you were building 3 ports in parallel, and each port build was running 3 jobs - that's 9 jobs in parallel on a low-spec CPU with 4 threads. You should limit the number of CPU-bound processes to the number of CPU threads you have. [1] cd /usr/ports/devel/llvm80 && make --=20 Peter Jeremy --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl76+kFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLKbgg//d0CZ8FCMHjXHzH5ZXM2edr7zbfF+JQZBhGY3t7M4xnMq5rQZtWd7pRzY i9Zes0vVqF21eMPDlJSL0DJ8gJmyrxauMZ+1TNx2JvpRIAqK77v4LuUrzXKjjcn6 qVObiwzaAocMEk02ghb5EGZGZcmAO4G2Ww3Fh2cbx2wBs6b2z8mzqAA4xTI4klaY ueP77RRu4IxJeIH98FanlEfFfeS3CoI2qKMBeAylHABKYJPqghnkGwWrX+UKyeY5 lmljeH2p5Cm+/1TxpuWPm/xKXcq+QK9svZKxTKfZ+4BWFx8goqRYlwgnvFQbhgAl LBBtIBbtokZ4XhoXVoeFbpTu8pqWRyDjwrrg+Aw/AfVcvIxI6cRXbw9rjVt900w6 ayb+b0UPul9Ki6xZclteoDFsPZC9PDgiDO0EqS86h8ihZ/1qQjLt9zpxR8xwkNIf Qrud2nA+Da1T3qYyXWZ8fApb2iXzJ0luDJrUVD9yAh7pREtfJFcueHVJsKLPi/uv g36zPSvp5fIlqvXVL4wJDVXxiV2OqU+Ds6LYaqIIGsg1qHddUz+hs3crD7LArSEQ OaV5fmThYjtOTIVgel7VYcNbY5FkMgvDj6i/h7sWC1mnvxqqPkRK9G9X5WKx9Tyj Ois6VvZ1+7iOSDg6apvOKbMwki+bQjFHZZ8/CPO6IkEOJalob7A= =FiWs -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-stable@freebsd.org Wed Jul 1 10:07:01 2020 Return-Path: Delivered-To: freebsd-stable@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 8087434A59D for ; Wed, 1 Jul 2020 10:07:01 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xcMm38Dnz4FRW for ; Wed, 1 Jul 2020 10:07:00 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [178.93.61.179] (helo=localhost) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqZdk-0002Va-PX for freebsd-stable@freebsd.org; Wed, 01 Jul 2020 10:06:52 +0000 Date: Wed, 1 Jul 2020 13:06:49 +0300 From: Nick Kostirya To: freebsd-stable@freebsd.org Subject: BerkeleyDB Hash vs Btree on FreeBSD and Linux Message-ID: <20200701130649.0b0643d5@i11.co> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i386-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49xcMm38Dnz4FRW X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.26 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[i11.co:s=omicron]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.003]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.02)[-1.019]; DKIM_TRACE(0.00)[i11.co:+]; DMARC_POLICY_ALLOW(-0.50)[i11.co,reject]; NEURAL_HAM_SHORT(-0.24)[-0.242]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[178.93.61.179:received] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 10:07:01 -0000 Hello. I noticed that BerkeleyDB Hash is VERY slow compared to BerkeleyDB Btree on FreeBSD (UFS or ZFS). But they (Hash and Btree) have roughly the same performance on Linux. Why? From owner-freebsd-stable@freebsd.org Wed Jul 1 10:20:33 2020 Return-Path: Delivered-To: freebsd-stable@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 44C4D34A9D7 for ; Wed, 1 Jul 2020 10:20:33 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49xcgN3GX3z4G2M for ; Wed, 1 Jul 2020 10:20:32 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yb1-f172.google.com with SMTP id y13so11694322ybj.10 for ; Wed, 01 Jul 2020 03:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vRf94bD/5ABwZPva4k3g0XgjBQ7liK3RXab7bC2ABqc=; b=maxrUegZtMEunx5EL4t9AVUevPqHrsioeJmsxlLnsYb/5piNvn+plc0w5AOUIRWohn xkmqmhFopfgp5OjJijYzPhluDloRBrzmTZazbOZ6IuAY2cTo67Kv5RFJ84Xq75SgfJTO iLFz2GwmKU/wSksQMZYSm7pycoR2pbIs1ec4j8LvObJCATBb5Kwz58sDcqMnh+Xppj8h MIpgoIwv8wPPKG0C+DQ+O12sLapBb2LN5zIdO34JgjgzuDbWy6YBnw6lq6Gj1XfJ5qqD 17VheeY/IV25eMhDvDUs0SoQIzMIABe/eiRk2TJPFuPUHJSU2MNteJwuPecL+m6cP5tV QYOQ== X-Gm-Message-State: AOAM532qKHiKGhLQc0letc7if8FCuAR/LXyrt0lbSWB2A7ibdzeXk5ar 65SQd3pnOfpb5OLF3NXL6HLnZ47I7xdzRzuP1zW/yJw2 X-Google-Smtp-Source: ABdhPJwPhb0+GEzyiaWyb0q8n7fgKwmkRAEdZM4fS3if1rFgNLkNsldpVl7o+Lh7H7nZaHjipI6ir5o3JNMuI4I/DQk= X-Received: by 2002:a25:d088:: with SMTP id h130mr42446326ybg.451.1593598831302; Wed, 01 Jul 2020 03:20:31 -0700 (PDT) MIME-Version: 1.0 References: <20200701130649.0b0643d5@i11.co> In-Reply-To: <20200701130649.0b0643d5@i11.co> From: Li-Wen Hsu Date: Wed, 1 Jul 2020 18:20:19 +0800 Message-ID: Subject: Re: BerkeleyDB Hash vs Btree on FreeBSD and Linux To: Nick Kostirya Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49xcgN3GX3z4G2M X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-2.42 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.914]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.97)[-0.970]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.53)[-0.533]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.172:from]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.172:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 10:20:33 -0000 On Wed, Jul 1, 2020 at 6:07 PM Nick Kostirya via freebsd-stable wrote: > > Hello. > > I noticed that BerkeleyDB Hash is VERY slow compared to BerkeleyDB Btree on FreeBSD (UFS or ZFS). > But they (Hash and Btree) have roughly the same performance on Linux. > > Why? It's not an easy question, do you have more information about the test environment setup, and the statistics of the results? I'd recommend using some analysis tools like DTrace to check what it's busy for. Li-Wen From owner-freebsd-stable@freebsd.org Wed Jul 1 12:07:01 2020 Return-Path: Delivered-To: freebsd-stable@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 B69DD34E349 for ; Wed, 1 Jul 2020 12:07:01 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xg2D6F5dz4Mqn for ; Wed, 1 Jul 2020 12:07:00 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [178.93.61.179] (helo=localhost) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqbVy-00040I-Pj for freebsd-stable@freebsd.org; Wed, 01 Jul 2020 12:06:58 +0000 Date: Wed, 1 Jul 2020 15:06:54 +0300 From: Nick Kostirya To: freebsd-stable@freebsd.org Subject: Re: BerkeleyDB Hash vs Btree on FreeBSD and Linux Message-ID: <20200701150654.74775e56@i11.co> In-Reply-To: References: <20200701130649.0b0643d5@i11.co> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i386-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49xg2D6F5dz4Mqn X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[i11.co:s=omicron]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.005]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; NEURAL_SPAM_SHORT(0.40)[0.396]; DKIM_TRACE(0.00)[i11.co:+]; DMARC_POLICY_ALLOW(-0.50)[i11.co,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[178.93.61.179:received] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 12:07:01 -0000 On Wed, 1 Jul 2020 18:20:19 +0800 Li-Wen Hsu wrote: > On Wed, Jul 1, 2020 at 6:07 PM Nick Kostirya via freebsd-stable > wrote: > > > > Hello. > > > > I noticed that BerkeleyDB Hash is VERY slow compared to BerkeleyDB Btree on FreeBSD (UFS or ZFS). > > But they (Hash and Btree) have roughly the same performance on Linux. > > > > Why? > > It's not an easy question, do you have more information about the test > environment setup, and the statistics of the results? > > I'd recommend using some analysis tools like DTrace to check what it's busy for. The top show getblk status often. Please tell me what you can and how to look with DTrace. I use dtrace -n '::: /execname == "a.out"/ { @[probefunc] = count(); }' but I do not see the difference between Hash and Btree. From owner-freebsd-stable@freebsd.org Wed Jul 1 16:00:58 2020 Return-Path: Delivered-To: freebsd-stable@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 7C049355CC9 for ; Wed, 1 Jul 2020 16:00:58 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yb1-f193.google.com (mail-yb1-f193.google.com [209.85.219.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49xmD954V1z4h5K for ; Wed, 1 Jul 2020 16:00:57 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yb1-f193.google.com with SMTP id y17so10111097ybm.12 for ; Wed, 01 Jul 2020 09:00:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pI4fUiPfxb00/zf2AjkO1Qo0FejzD9olJX6I6LspalE=; b=cEt4lbZkBi4x2Y0Xmlv5yL8hq1rKe9tAC0yywHb6PS+QqA+dwrI0O45iiIz2yEr45u MNDCaPKGXuOAf9eSveOZBeHZzp4FV3gONEpOWS3CCb3gOtAR2qXXHRxOs5JrftFMdtNh axMzrqmhUyacNkEM9gJGD4asVf9D77CrTDt4boOGibP9AbnoQnulkd5wqgIE8tvVuSik wVX4NyDPotV7SXE9L6v7/PafzTQvRZxyp2uGMH80a+CxABInqx299AstcYkTVkVUL88+ FRxxqZr1GsDXqbFr9NEYHOzqEJZxMo9n/gq3odaw3FQzIKK339kQDlr6gz9c6lX17Bij vmVg== X-Gm-Message-State: AOAM533ONq506/HemTd9+EALmSQijkc8+JCbDH8u+WkKZ/RBoTwzDqbI dmykUe6Cf14CwRV14kijEdJNrxhPaw1qSiN+YUs= X-Google-Smtp-Source: ABdhPJx09YP4etmD4vK4o9r7qGeuhVed+UHJ7vdF7HBAly2y1IJzR9ao8FxvO+Mp+1XILQZ90jsJmqso5BVccnZRimY= X-Received: by 2002:a05:6902:4a2:: with SMTP id r2mr44394730ybs.176.1593619254113; Wed, 01 Jul 2020 09:00:54 -0700 (PDT) MIME-Version: 1.0 References: <20200701130649.0b0643d5@i11.co> <20200701150654.74775e56@i11.co> In-Reply-To: <20200701150654.74775e56@i11.co> From: Li-Wen Hsu Date: Thu, 2 Jul 2020 00:00:42 +0800 Message-ID: Subject: Re: BerkeleyDB Hash vs Btree on FreeBSD and Linux To: Nick Kostirya Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49xmD954V1z4h5K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.219.193 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-2.36 / 15.00]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.97)[-0.966]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.41)[-0.412]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.193:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.193:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 16:00:58 -0000 On Wed, Jul 1, 2020 at 8:07 PM Nick Kostirya via freebsd-stable wrote: > > On Wed, 1 Jul 2020 18:20:19 +0800 > Li-Wen Hsu wrote: > > > On Wed, Jul 1, 2020 at 6:07 PM Nick Kostirya via freebsd-stable > > wrote: > > > > > > Hello. > > > > > > I noticed that BerkeleyDB Hash is VERY slow compared to BerkeleyDB Btree on FreeBSD (UFS or ZFS). > > > But they (Hash and Btree) have roughly the same performance on Linux. > > > > > > Why? > > > > It's not an easy question, do you have more information about the test > > environment setup, and the statistics of the results? Any information about this? > > I'd recommend using some analysis tools like DTrace to check what it's busy for. > > > The top show getblk status often. > > Please tell me what you can and how to look with DTrace. > > I use > dtrace -n '::: /execname == "a.out"/ { @[probefunc] = count(); }' > > but I do not see the difference between Hash and Btree. I would say check the flame graph: http://www.brendangregg.com/blog/2015-03-10/freebsd-flame-graphs.html There is benchmarks/flamegraph port but I haven't used it for a while. Li-Wen From owner-freebsd-stable@freebsd.org Fri Jul 3 13:36:06 2020 Return-Path: Delivered-To: freebsd-stable@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 9AF4934EDA4 for ; Fri, 3 Jul 2020 13:36:06 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yww53nxMz4JCW for ; Fri, 3 Jul 2020 13:36:05 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [178.93.45.16] (helo=localhost) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jrLrB-0006KH-U8 for freebsd-stable@freebsd.org; Fri, 03 Jul 2020 13:35:58 +0000 Date: Fri, 3 Jul 2020 16:35:54 +0300 From: Nick Kostirya To: freebsd-stable@freebsd.org Subject: Re: BerkeleyDB Hash vs Btree on FreeBSD and Linux Message-ID: <20200703163554.68a87960@i11.co> In-Reply-To: References: <20200701130649.0b0643d5@i11.co> <20200701150654.74775e56@i11.co> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i386-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yww53nxMz4JCW X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.76 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[i11.co:s=omicron]; RECEIVED_SPAMHAUS_PBL(0.00)[178.93.45.16:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.965]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; DKIM_TRACE(0.00)[i11.co:+]; DMARC_POLICY_ALLOW(-0.50)[i11.co,reject]; NEURAL_HAM_SHORT(-0.84)[-0.843]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 13:36:06 -0000 The question is being removed. I found out that the big difference is only for the HDD, but not for the SSD. And the difference is very noticeable on long values (> 5000). But I still did not find the conditions when the hash is better. I will use only btree from now. On Thu, 2 Jul 2020 00:00:42 +0800 Li-Wen Hsu wrote: > On Wed, Jul 1, 2020 at 8:07 PM Nick Kostirya via freebsd-stable > wrote: > > > > On Wed, 1 Jul 2020 18:20:19 +0800 > > Li-Wen Hsu wrote: > > > > > On Wed, Jul 1, 2020 at 6:07 PM Nick Kostirya via freebsd-stable > > > wrote: > > > > > > > > Hello. > > > > > > > > I noticed that BerkeleyDB Hash is VERY slow compared to BerkeleyDB Btree on FreeBSD (UFS or ZFS). > > > > But they (Hash and Btree) have roughly the same performance on Linux. > > > > > > > > Why? > > > > > > It's not an easy question, do you have more information about the test > > > environment setup, and the statistics of the results? > > Any information about this? > > > > I'd recommend using some analysis tools like DTrace to check what it's busy for. > > > > > > The top show getblk status often. > > > > Please tell me what you can and how to look with DTrace. > > > > I use > > dtrace -n '::: /execname == "a.out"/ { @[probefunc] = count(); }' > > > > but I do not see the difference between Hash and Btree. > > I would say check the flame graph: > http://www.brendangregg.com/blog/2015-03-10/freebsd-flame-graphs.html > There is benchmarks/flamegraph port but I haven't used it for a while. > > Li-Wen > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Jul 3 15:47:51 2020 Return-Path: Delivered-To: freebsd-stable@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 EE040351A4D; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yzr75xL0z4QQL; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id BC99018A3C; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) Date: Fri, 3 Jul 2020 15:47:51 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-06-28 Message-ID: <20200703154751.GA89871@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:47:52 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-06-28 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-06-22 to 2020-06-28. During this period, we have: * 2388 builds (94.4% (+0.5) passed, 5.6% (-0.5) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 283 test runs (89.1% (+9.3) passed, 10.2% (-2.9) unstable, 0.7% (-6.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 96.0 doc and www builds (96.0% (-4.0) passed, 4.0% (+4.0) failed) Test case status (on 2020-xx-xx 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | -------- | | head/amd64 | 7857 (-6) | 7766 (+2) | 0 (0) | 91 (-8) | | head/i386 | 7855 (-6) | 7754 (-2) | 0 (0) | 101 (-4) | | 12-STABLE/amd64 | 7593 (+2) | 7535 (+3) | 0 (0) | 58 (-1) | | 12-STABLE/i386 | 7591 (+2) | 7525 (0) | 0 (0) | 66 (+2) | | 11-STABLE/amd64 | 6888 (+1) | 6837 (+3) | 0 (0) | 51 (-2) | | 11-STABLE/i386 | 6886 (+1) | 6833 (0) | 0 (0) | 53 (+1) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200628 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Fixed test cases * bin.sh.execution.functional_test.bg12 https://bugs.freebsd.org/247559 ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * (head, stable/12, stable/11) 2 tests start failing after llvm10 import * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 646 failures, 826 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) (new) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 (new) ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 (new) sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg)