Date: Thu, 14 Apr 2016 16:04:27 -0600 From: Warner Losh <imp@bsdimp.com> To: Dmitry Morozovsky <marck@rinet.ru> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci Message-ID: <CANCZdfp8iJJoVZd-xQXqxpVsB5PiocTTcFVW-Vxkn6zX3OMUfw@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1604150051440.76365@woozle.rinet.ru> References: <201604142147.u3ELlwYo052010@repo.freebsd.org> <alpine.BSF.2.00.1604150051440.76365@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 14, 2016 at 3:54 PM, Dmitry Morozovsky <marck@rinet.ru> wrote: > Warner, > > On Thu, 14 Apr 2016, Warner Losh wrote: > > > Author: imp > > Date: Thu Apr 14 21:47:58 2016 > > New Revision: 298002 > > URL: https://svnweb.freebsd.org/changeset/base/298002 > > > > Log: > > New CAM I/O scheduler for FreeBSD. The default I/O scheduler is the > same > > [snip] > > First, thanks so much for this quite a non-trivial work! > What are the ways to enable this instead of deafult, and what ar the > benefits > and drawbacks? You add CAM_NETFLIX_IOSCHED to your kernel config to enable it. Hmmm, looking at the diff, perhaps I should add that to LINT. In production, we use it for three things. First, our scheduler keeps a lot more statistics than the default one. These statistics are useful for us knowing when a system is saturated and needs to shed load. Second, we favor reads over writes because our workload, as you might imagine, is a read mostly work load. Finally, in some systems, we throttle the write throughput to the SSDs. The SSDs we buy can do 300MB/s write while serving 400MB/s read, but only for short periods of time (long enough to do 10-20GB of traffic). After that, write performance drops, and read performance goes out the window. Experiments have shown that if we limit the write speed to no more than 30MB/s or so, then the garbage collection the drive is doing won't adversely affect the read latency / performance. There's likely a few rough edges still, since we run primarily UFS in production and I've only tested it with ZFS on my home server running plex. I wrote a paper about it, though it likely needs to be updated a bit. It's near enough to what I just committed, though, to be useful: https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf > This code has run in production at Netflix for over a year now. > > Looking at this: could it be possibly targeted for MFCing? > While this has been running in 10.x stable for the past year on our servers, I have no plans to MFC it at this time. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp8iJJoVZd-xQXqxpVsB5PiocTTcFVW-Vxkn6zX3OMUfw>