From owner-freebsd-arm@freebsd.org Thu Jun 14 09:25:03 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 3A60E101509C for ; Thu, 14 Jun 2018 09:25:03 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2E0C7FAE5 for ; Thu, 14 Jun 2018 09:25:02 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-ua0-x233.google.com with SMTP id s13-v6so3656500uad.2 for ; Thu, 14 Jun 2018 02:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jiwyRPx4Zk9vKxUzgFfPzgUe8ks4r6aulDCQH7l6Ijg=; b=txS+2RTUi6cVBCpJQhoKaDIPbdJf7pUGTn6TR0232DeJtoJn0avIKs9bytuHVDv+ZD V0NzSUZX97/QyvocXXuLbQ6Dav3MWBGfhWims55RUg1LJnPe7EVU3Sbdnz3CCAf1oErL 9nainIxvmyGbwY5yEIIQV0/bzst+xawjcc/l2iMgP625cu3FzKRLmceKceZbwr/19dAc qY/jU5jGY4HNn7n6kc/Q9mhWQlgLE2iNKeq8rCinvVf8vUcDx5HCr2pDyBH5HX+P3bjf MlP1IEdP0NQ4x7zVFo8d6n17nC/GnX5kcBFZri9oSplRsMpgFsUQdELIbbwUdYuqOtli ETmw== 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=jiwyRPx4Zk9vKxUzgFfPzgUe8ks4r6aulDCQH7l6Ijg=; b=hT7wHGSK6ZkfMyerrnaXdrTTF6fkND8gIExJxNWLlRuFNjZlhxZwYL0hyyeiXGybdK cCxlXmLAkWHkpX1GAvrw1yJhGYkUHmcsQ9x2agdp9ITUS/qmAghSRhrp4jqK/GTk/iON YBwYZ+VeaZIF6URNOp/jDT5AZdXamjZFzRUnMyRl6rkmBImFFliPU/k0sdI8GnOmo6tc z97Q7f7PQjl5mBow2z+C+XCVHta7hmhIllfC25j+A7rTJcqWTTq4qQ8gGHDqdb8HzDw8 LLL8FP+Fy60H0+3rvXzwCENHmpOD3GZ21sxdenV7WuS1CxHUrIN907TgE8xe+sTrlkql wMrQ== X-Gm-Message-State: APt69E1lCRkSHIAxw15Zol1WmcXffHeBhjAqD+MaPdcMPYDQT71ozyzV XWyslSM2Rc04AFzM+/+4FtCgfeN5lrG0CDW6/AkxgQ== X-Google-Smtp-Source: ADUXVKLXrlHxkF50eD8J+R5rHTcn9y13vSqdaaG0rIgGA5ygFhl6AcwO/9oFXFbl4CYeZ0iRVfyvGC2+w2faThhej3E= X-Received: by 2002:ab0:517a:: with SMTP id f55-v6mr1143321uaa.90.1528968302055; Thu, 14 Jun 2018 02:25:02 -0700 (PDT) MIME-Version: 1.0 References: <20180613154826.GA24146@www.zefox.net> <20180613183730.GA24526@www.zefox.net> In-Reply-To: From: Tom Vijlbrief Date: Thu, 14 Jun 2018 11:24:50 +0200 Message-ID: Subject: Re: GPT vs MBR for swap devices To: Mark Millard Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 09:25:03 -0000 I am torturing myself by doing build worlds on an original rpi with just 256Mb memory. I used to use an usb hard disk for swap and for /usr/{src,obj} but that disk has died. Currently swapping on an NFS swap file (this Linux server also hosts /usr/{src,obj} ) which works surprisingly well. The user %cpu is much better when swap is heavily used (often > 90%) compared to the old usb disk setup. The latency of the NFS server is quite small, even with the slow 100mbit rpi Ethernet. Op wo 13 jun. 2018 23:42 schreef Mark Millard via freebsd-arm < freebsd-arm@freebsd.org>: > On 2018-Jun-13, at 11:37 AM, bob prohaska wrote: > > . . . > > Some of the combinations trigger the warning: > > > > warning: total configured swap (1048576 pages) exceeds maximum > recommended amount (918256 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > As I remember, the "increase kern.maxswzone" only applies if one has > previously decreased it: the modern default is the maximum recommended > as I remember (allowing for for half the theoretical maximum swap). If > I remember right the code overrode attempts to set more than the > default, only setting less (when requested). (I've not re-validated > this claim via a code inspection in some time.) > > Quoting "man 8 loader" and its kern.maxswzone material, > > Note that swap metadata can be fragmented, which means > that > the system can run out of space before it reaches the > theoretical limit. Therefore, care should be taken to not > configure more swap than approximately half of the > theoretical maximum. > > So it will potentially have more fragmentation problems fitting the > extra metadata that is involved in the same amount of total RAM. > > I will note that aarch64 and armv7 for the same amount of RAM use > very different "maximum recommended amount"s. (Compare an armv7 rpi2 > to an aarch64 rpi3 by adding enough swap to get the notice, for > example. The rpi3 allows far more swap space as I remember.) This > variability is not obvious from the man page's material. > > > which I've ignored, thinking the system will ignore excess swap space. > > Again: It will potentially have more fragmentation problems fitting the > extra metadata that is involved in the same amount of total RAM. > > > Is > > this mistaken? > > I expect so because of the metadata issue. (But some later > notes below go in another direction, making this possibly > not a unique source of overall behavior differences.) > > > It's pretty clear the system does not need more than about > > 1.5 GB of swap. Available swap devices are presently sized like so: > > I'd recommend not using a whole lot more than you need, at least > small enough (total) for it to not report the warning. > > One thing I wish FreeBSD had was an (approximate) "Maximum Observed > Swap Used" that could be queried or that some built-in tool would > monitor and report. At times I've made variants of top that displayed > such based on the figures it uses for its swap line. I've made > judgements about -jN choices and swaps space sizes based on what I've > observed for various contexts that I use/do repeatedly and for "large" > things that I do rarely but that can fail in my normal configuration. > > > 3 GB mechanical disk > > 2 GB microSD flash > > 1 GB microSD flash > > 1 GB USB flash > > To make your experiments comparable, I'd recommend the same total > swap be used across the alternatives being tested and compared. > This may be biased to using a smaller swap space that all the > contexts can support. > > Going in another direction: The timing variations between the types > of media may mean that the mix of what is happening at the same time > changes for -j4 from one context to the next. This could get other > issues involved in why there are variations in the overall behavior. > > > Side note: I've used eMMC on an adapter in some microSD slots. I > had to "adjust" the Pine64+ 2GB case for the adapter that I used > to reach so such is not always an automatically-available option. > > > The original plan was to use the two 1 GB flash partitions in the hope > > they'd interleave, but that does not work at all. The microSD flash > > swap seems to work fine. I was wondering if the USB mechanical swap > > might point to trouble in the USB side of things, but it does not. > . . . > > > Just for completeness for other readers (you may well be using swap > partitions) . . . > > I also recommend swap partitions instead of swap files. See, for > example: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 > > > (OOM process kills were not one of the issues for bugzilla 206048. > But there were other problems for swap files.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >