From owner-svn-src-head@freebsd.org Sat Feb 16 18:14:55 2019 Return-Path: Delivered-To: svn-src-head@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 C59B414F0780 for ; Sat, 16 Feb 2019 18:14:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 5713A94FAC for ; Sat, 16 Feb 2019 18:14:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id p25so14448776qtb.3 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=X6E+XiXOJgJSL5SmI42t55MjlackQ1w1VGdN5w7SbxhXioIobnKBmCNFkpoYVcs0ct TV6dlMEwYWXrmaT8caUxWz0YwgCqOx9tTAByXdelCCkSawuEn7HNVwXX24pA9htP8LzN CaZc2FtriC4h1s/WGwN4oghLOyB3yTKhw++dq+P/fJcreb9pg7sUtJBDF25ID4VAKmVO hkC/ib2il7z8Q4C9eGdMPVf2/MKrq96gYArXX+bsJQgVR8zUDMLHWpNX4zN6ONQ/GoDq TlB6aw8D0frB/KcW1F0cYZkmSWWYy7LPUHdLEK9i9ypw3nmpcqa06PlJx7gtXpQHxSFh DM6Q== X-Gm-Message-State: AHQUAuYtOn5bjj5zABzIWoNwQp7Dv70ODiEoSCxV1VipSMndvu1Nt53B oMO2i+9eHp0O0bljc18Edn9C4NAheE3n21C2tMmLKA== 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: 5713A94FAC 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-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current 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 >