From owner-freebsd-arm@freebsd.org Fri Jun 22 02:09:02 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 946C9100A6DB for ; Fri, 22 Jun 2018 02:09:02 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEF7979874 for ; Fri, 22 Jun 2018 02:09:01 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5M28uFf015372 for ; Fri, 22 Jun 2018 12:08:56 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices To: freebsd-arm References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> From: Trev Message-ID: Date: Fri, 22 Jun 2018 12:08:56 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Fri, 22 Jun 2018 12:08:56 +1000 (AEST) 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: Fri, 22 Jun 2018 02:09:02 -0000 Mark Millard via freebsd-arm wrote on 22/06/2018 00:51: > On 2018-Jun-21, at 12:28 AM, Trev wrote: > >> I gave in and bought an Raspberry Pi 3B+ and now I've been bitten by Bob's OOM assassin too... >> >> % gpart show >> => 63 31116225 mmcsd0 MBR (15G) >> 63 2016 - free - (1.0M) >> 2079 102312 1 fat32lba [active] (50M) >> 104391 31008825 2 freebsd (15G) >> 31113216 3072 - free - (1.5M) >> >> => 0 31008825 mmcsd0s2 BSD (15G) >> 0 57 - free - (29K) >> 57 31008768 1 freebsd-ufs (15G) >> >> => 40 60567472 da0 GPT (29G) >> 40 4194304 1 freebsd-swap (2.0G) >> 4194344 56373168 2 freebsd-ufs (27G) >> >> % cat /etc/fstab >> # Custom /etc/fstab for FreeBSD embedded images >> /dev/ufs/rootfs / ufs rw,noatime 1 1 >> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >> md1 /tmp mfs rw,noatime,-s100m 0 0 >> md2 /var/log mfs rw,noatime,-s15m 0 0 >> md3 /var/tmp mfs rw,noatime,-s15m 0 0 >> /dev/ufs/swap none swap sw 0 0 >> /dev/ufs/usr /usr ufs rw,noatime 2 2 >> >> da0 is a brand new 32G EMTEC USB2 memory key housing /usr and swap partitions. >> >> FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >> >> make -j4 buildworld resulted in: >> >> Jun 21 17:05:12 rpi3 kernel: pid 10326 (c++), uid 0, was killed: out of swap space >> --- CodeGen/AsmPrinter/CodeViewDebug.o --- >> c++: error: unable to execute command: Killed >> c++: error: clang frontend command failed due to signal (use -v to see invocation) >> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) >> Target: aarch64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. >> c++: note: diagnostic msg: >> >> I happened to have been watching top (5 second interval) at the time and of the >> 2G swap, only 45M was shown to be in use. > Are you getting errors such as those listed in: > > https://lists.freebsd.org/pipermail/freebsd-arm/2018-June/018091.html No - I have no such errors. > If not, your context may be a better test case than Bob P.'s. > > It looks like the latest from Bob P. is that when his /dev/da0 > is not used for swap (and so has far less I/O) his builds finish, > apparently without logging errors: > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_1.3gbusbmechanical_swapinfo/readme > > where he writes: > >> This test used the 1 GB SD flash swap partition plus a 1.3 GB partition >> on a USB mechanical disk. The -j4 buildworld ran to completion without >> obvious errors, serving mostly to suggest there's nothing wrong with >> the read/write behavior of /dev/da0, the USB flash drive holding /usr >> and with it /usr/obj. > > (I do not share his conclusion about /dev/da0 based on the smaller > amount of I/O when it was not used for swapping.) > > As far as I know the swap system is far more dependent on timely > I/O than the other I/O involved in a build. > > Even without errors considered Bob was getting things like the > large ms/w figures below: > >> Mon Jun 18 09:42:05 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >> dT: 10.043s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0 >> 46 0 0 0 0.0 0 16 12355 0 0 0.0 85.9 da0 >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3a >> 33 0 0 0 0.0 0 22 12318 0 0 0.0 114.1 da0d >> Mon Jun 18 09:42:25 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% > > Are you getting such during the swapping activity? I have seen similar large mw/w when buildworld is writing to da0, I haven't noticed it when swapping but it's possible. Unfortunately my rpi3B+ is not a direct comparison with the rpi2B because I only had the one USB2 memory device holding /usr, /usr/obj and swap. I'll try moving swap to a dedicated USB2 memory device.