svn commit: r344188 - in head: lib/libc/sys sys/vm
imp at bsdimp.com
Sat Feb 16 18:14:55 UTC 2019
On Sat, Feb 16, 2019, 10:08 AM Ian Lepore <ian at 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.
More information about the svn-src-all