From owner-freebsd-arm@freebsd.org Wed Jun 13 16:09:22 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 396921019396 for ; Wed, 13 Jun 2018 16:09:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 BC4D06B360 for ; Wed, 13 Jun 2018 16:09:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id g7-v6so3993631ioh.11 for ; Wed, 13 Jun 2018 09:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=H+iUrrMi7lATmndFPsVim+tG34gkceJ9K4G4j9puzzk=; b=eZz46bAFGcme4VT10Pkano+cV5TqmjUCkSzZiarSe8rJ+4jjizuDBYT7Hr+kEoyZTq 5rDtWeJlCb0H+8H7GB7dCagvC8FAz41eUJC8X43PeAKB5JKD2cE114I6QFtSTlFXUzkQ zx3KpELfslWQB26MY/By7ShWz46YfF1o4KrpnwgLfDSSO7oFvNAJsR4AKmJ9Nvj5me01 XuxWlsg/TWSXiJIN9qxH0/t06VlObHYI42z5uWVtv9xCPu3vVdL5xMJ1ZmcKzFj363b8 S2uxCUN4p7tClubuPKgDpuFGGLfoKTep1uUdVCqoR6S5l1L7MdKHaT7fLb0tzKv1yvlh cvVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=H+iUrrMi7lATmndFPsVim+tG34gkceJ9K4G4j9puzzk=; b=iORgqGJUd3wVBst6SCz1uhSnsGPw8C7/Jfcru+IEhIBF9+jtqh9RJe+B+56ax6ZCMl YRXLQISnPL0BGCxnzMt0wlT2rZq0YxHegP8OokRZO3kLw1A7/agnxrnoVIZdgYUkgRQe pc7/pmliCo0Hb845q9lqO2AcVBnYWBwQBow7DwcVkD6C6735c6uLEdRmssSBtZJE5uaD +2AJZNtuzwOv4opg53g6+aaagBQupPP+lfqhQuoDuMMvdBqbZ4Q90lHg/ze5SeuLjBAF osvPzCmbiOQMUW1DhDPqBoSQxQ4n6tUAlwzz0VMzLgWUv9TA3Sr1tWu6/BHI5s0J2ZTr 9dzQ== X-Gm-Message-State: APt69E3JXPHDJa2k50IccpG1KhYNezuzbWRLvY5e8HUmw2GBMhRrioxv irhdnvZ9phbTsky23mK/tV2WYZf9b1GwiVHov1y6sg== X-Google-Smtp-Source: ADUXVKItyKrqhu1dOJ1mGp0xNj5li9JQJ0dHX3US/ow6/ZfKXHZ0sW5r91tcRKgvh9B+WcCmQAiexEhPNBx3UQQ6bNA= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr5162247iop.299.1528906160857; Wed, 13 Jun 2018 09:09:20 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:d028:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 09:09:20 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180613154826.GA24146@www.zefox.net> References: <20180613154826.GA24146@www.zefox.net> From: Warner Losh Date: Wed, 13 Jun 2018 10:09:20 -0600 X-Google-Sender-Auth: _AzAfjDb5M-AT6LtHZC08ZsWPcE Message-ID: Subject: Re: GPT vs MBR for swap devices To: bob prohaska Cc: "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: Wed, 13 Jun 2018 16:09:22 -0000 On Wed, Jun 13, 2018 at 9:48 AM, bob prohaska wrote: > In trying to get a Pi3 at r334939 to run -j4 buildworld it's become clear > that a USB flash (Sandisk Extreme) swap device very quickly triggers OOM > process kills, while a USB mechanical disk swap devices works perfectly. > > It's somewhat hard to believe that the Sandisk Extreme is much slower than > a mechanical hard drive for small reads and writes if the rated speeds are > anywhere close to correct, but it happens that the flash device uses MBR > partitioning, while the mechanical hard drive uses GPT. > > Is there any reason to think that the partitioning scheme matters? > Usually, partitioning doesn't matter. USB flash drives are optimized for (a) being big and (b) writing large files, infrequently. Neither of these is good for swap space. So, lots of 'small' writes that the swapper does can often trigger pathological behavior in the drive's FTL (that's a polite way to say performance goes through the floor). I've seen on SSDs, which have better FTLs, that can easily do 500MB/s drop to 10-20MB/s when reads and writes are mixed with the wrong workload. Our swapper is written with the assumption that all writes are equal and small ones are better than larger ones (since they free up the dirty pages faster). However, you can often get better performance out of larger writes and I don't think there's a knob to twist for that. I should have added (c) and sometimes for FAT file systems. That used to be the case. And for that MBR used to be a little better. However, that was 5 years ago or so. With the new Sandisk Extreme drives it isn't so much since they are so large and FAT isn't good enough for most people these days. My experience with them recently has been they are OK drives. The write speed is kinda crappy (maybe 50-60MB/s when streaming a file to them, and 20-3MB/s in a mixed workload), but their read speed is surprisingly good at up to about 200MB/s when there's no flash contention. My main concern, though, was copying a 16GB video to them and making sure it would play back OK. For that they are good. For backing up the video project with all it's little files, not so good, and doing 'du' on it while copying slowed the copying down a lot, even though it wasn't that much traffic to the drive. All of this was on macOS, though. Warner