From owner-svn-src-all@freebsd.org Sat Feb 16 18:14:55 2019 Return-Path: Delivered-To: svn-src-all@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 E104014F0781 for ; Sat, 16 Feb 2019 18:14:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75BDA94FAD for ; Sat, 16 Feb 2019 18:14:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id j36so14698676qta.7 for ; Sat, 16 Feb 2019 10:14:54 -0800 (PST) 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=cBPFuAXCQazm2hk/+9iVwqxJG9guIwkqXTeMazMsowk=; b=l7eElwIZkg6TCBYqhVLhFDi8Cm4FXsXNYev5YCSViRXR8Zk/bJt+b3f/ir04EDIlOh dGFq1xM545Eu5NEsQZChwFUxINOhG+zGNiHNbxeGMUCN3vdj91o++E4ztKAEdzp762e/ M6w8WRNLcxCCGvAxofBLF82waaJ/LD8LgEnKlfvnomIRit3qNs/tYCAAPQy8zw8e+621 lsnzwYePTm2MgyS36jQKfj8kxZ9ZDUnPVP/l5At2ENap5LQD2jBGUSd+Q3OVhKmWzmfi Rlbu/6rPAPsZlsWoSbpcSw9pu7aOeajMLZfAolBESbthrYjj0/3VqkU8nx2Dgvwhz+Et ItcA== 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=cBPFuAXCQazm2hk/+9iVwqxJG9guIwkqXTeMazMsowk=; b=PXPGIZ9+28BsvpNDqe7yOzBTEllipOvBLrSkCNbTAa5ErRWV4LtGu+pYgzusEDHet4 tXghxApqL2KKGy8kWoAgmoi9IrJDMGRl99esrZc/Tt9DGLUzpnbfeR7T625+99+TRmkC ivgr/xSTCM5vuXANmT0Vi8gUY5OPygzDIwXTA8wYHD84/q4xMcjZmR7k/JhaCbf5H4Df KFJB1lsa+154z3zJgvjYjfV+TPaP1/axe4Nf8aLNxH38vZnqkMNPaveuL7Ee5Z/aI71F g48t2X+fLVwVaF4gyrevms5n4ztZ7l1YyU8d6T6UVHFEH41eFtd3L+VabB+SuQY/RHxL dUuA== X-Gm-Message-State: AHQUAubbgTi7l8vf+AljoWm17rfUxs3j/dg0xwngc/weMpfhc1NgN2qj eff+PVJfvo76M1iGwBSqZL/uy1C4Hfi5JRKGpHjIfQ== X-Google-Smtp-Source: AHgI3IbwGt8zFq//Tq8MFyoVEeLER0GqnagUNKZzTIbBIjzZKgN5b6nYHIo7xPZZs+b+eJK+rAjg/N6u/s1wZsxuqU8= X-Received: by 2002:ac8:35f8:: with SMTP id l53mr12666526qtb.15.1550340892619; Sat, 16 Feb 2019 10:14:52 -0800 (PST) MIME-Version: 1.0 References: <201902152336.x1FNaNUo039321@repo.freebsd.org> <20190217011341.S833@besplex.bde.org> <259b30371291398891b48c38fc8231e7422f47e4.camel@freebsd.org> In-Reply-To: <259b30371291398891b48c38fc8231e7422f47e4.camel@freebsd.org> From: Warner Losh Date: Sat, 16 Feb 2019 11:14:40 -0700 Message-ID: Subject: Re: svn commit: r344188 - in head: lib/libc/sys sys/vm To: Ian Lepore Cc: Bruce Evans , Gleb Smirnoff , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: 75BDA94FAD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 18:14:55 -0000 On Sat, Feb 16, 2019, 10:08 AM Ian Lepore On Sun, 2019-02-17 at 02:58 +1100, Bruce Evans wrote: > > Slowness is relative. In FreeBSD-1, floppy disk devices were still in > > use and were especially slow. Now hard disks are slow relative to fast > > SSDs. But the number of buffers was unchanged. It is still essentially > > unchanged except for vn pager pbufs. The hard disks can complete 128 > > i/o's for a full queue much faster than a floppy disk, so the relative > > slowness might be similar, but now there are more subsystems and some > > systems have many more disks. > > The modern replacement for a floppy disk in this regard is an sdcard. > When doing large numbers of random writes, such as untarring a snapshot > of rootfs to a ufs filesystem on sdcard, gstat will show ms/w values > anywhere from 30,000 to 90,000 depending on the card. It stays that way > throughout the operation, and IO to all other disks on the system > essentially comes to a standstill. This is true whether the card is in > a native sdhci controller or a usb-attached multiformat reader/burner. > NAND FTL quality determines a lot of this. There are some things that can be done to make it better, but still not great. SD cards have crap FTLs, so are the worst. We should be smarter about how the upper layers schedule the IO down the stack. The way we do it now is turned for a narrow range of workloads and the SD card case is a significant outlier. IO times north of a second tend to hit the pathetic runningbuf limits which slows down writes to all devices, which is another factor in play in the random io sdcard case. I've done some incomplete work to help runningbufs that helps. Maybe it helps more now that the underlying allocation dynamics have shifted. Warner >