From owner-freebsd-arm@freebsd.org Wed Aug 15 11:21:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE91107FCEA for ; Wed, 15 Aug 2018 11:21:49 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 208AF86846 for ; Wed, 15 Aug 2018 11:21:48 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1534333009; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=lqkPwWuBsmBLPu9fwfcMR2dJx1KvsA009YKKZONx1to=; b=vBJNcmb7 UAXcbKr7klz9tQWReAijWasYhwEPUvfFEa0X02eCLtfz9W76qxTWEh3SyujDTmZSzfTbtUVNR1v6I 2D09lVmA/AspPeG646BnnsSajKyUCK3c/Am6KlkUUTwUumVv2UdeRsSdtOm/TRjdbS5wavPM6xmlD 3kw/yz1gWQfP+wac1bHno5iPZ8TMevDE4msTZCayMAr9epGeWYngjWjb6+Q5dLmZiZNBfpDgsa1mI dTIi55icMu7x6oO8oI6kZoZu3smsbT10f5/EcqDZp4BG4rvWx7qLQ8x4tTtvEqzLUmKN14J2EsXD6 Kpe2L/284fsTTIjvMSisqhe08g==; Received: from [10.45.79.71] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpts2-Wxjt6T-4b; Wed, 15 Aug 2018 11:21:46 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpts1-DuufZO-Av; Wed, 15 Aug 2018 11:21:45 +0000 Received: from dagobah.opaxus.net (173-28-113-92.client.mchsi.com [173.28.113.92]) by takodana.opaxus.net (Postfix) with ESMTPSA id C5E4B11A0F; Wed, 15 Aug 2018 06:21:43 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) From: Jedi Tek'Unum In-Reply-To: Date: Wed, 15 Aug 2018 06:21:42 -0500 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-Smtpcorp-Track: 1fpts1DIIfZOjv.dEzLLqk3S Feedback-ID: 207158m:207158azGM_-I:207158s4k39g8-gK:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 11:21:49 -0000 On Aug 14, 2018, at 11:26 PM, Warner Losh wrote: >=20 > So I think what's well tuned for the gear that's in a server doing > traditional database and/or compute workloads may not be so well tuned = for > the RPi3 when you put NAND that can vary a lot in performance, as well = as > have fast reads and slow writes when the mix isn't that high. The = system > can be tuned to cope, but isn't tuned that way out of the box. When there are no-win situations due to restrictive hardware then the = best solution is likely documentation encouraging people to avoid such = hardware. I doubt this is worth the effort of developing a kludge as one would = expect that these limitations will go away as hardware evolves - = rapidly. If people want to do things like -j4 on this kind of hardware then they = are asking for trouble. Might as well recommend swap over nfs. Surely not something one would = recommend on normal hardware but in this case it probably isn=E2=80=99t = any worse than slow NAND. However, I remain of the opinion that when people try to use hardware = unable to achieve minimal behavior that they should just suffer the = unresponsiveness. Surely thresholds can be recognized and warning syslog = messages provided. I=E2=80=99d rather have it sluggish than dying at = random times. I=E2=80=99ve not looked at OOM details on FreeBSD=E2=80=A6 Is there a = special signal sent to the victim before its killed? A quick glance at = the signal list says no. Of course that would introduce even more = complexity as the victim would need some reprieve time to be able to do = something with it. Even AIX had this in the =E2=80=9880s. My experience = back then was that it was better than nothing but not terribly useful.