Date: Sat, 16 Feb 2019 11:14:40 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344188 - in head: lib/libc/sys sys/vm Message-ID: <CANCZdfro1z7MsnB-sr7dXE043qvnfG6cmxtZYKs%2Bk0LHpoU4jQ@mail.gmail.com> In-Reply-To: <259b30371291398891b48c38fc8231e7422f47e4.camel@freebsd.org> References: <201902152336.x1FNaNUo039321@repo.freebsd.org> <20190217011341.S833@besplex.bde.org> <259b30371291398891b48c38fc8231e7422f47e4.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 16, 2019, 10:08 AM Ian Lepore <ian@freebsd.org wrote: > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfro1z7MsnB-sr7dXE043qvnfG6cmxtZYKs%2Bk0LHpoU4jQ>