Date: Thu, 14 Apr 2016 18:15:17 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Dmitry Morozovsky <marck@rinet.ru>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci Message-ID: <20160414221517.GA66711@mutt-hardenedbsd> In-Reply-To: <CANCZdfp8iJJoVZd-xQXqxpVsB5PiocTTcFVW-Vxkn6zX3OMUfw@mail.gmail.com> References: <201604142147.u3ELlwYo052010@repo.freebsd.org> <alpine.BSF.2.00.1604150051440.76365@woozle.rinet.ru> <CANCZdfp8iJJoVZd-xQXqxpVsB5PiocTTcFVW-Vxkn6zX3OMUfw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2016 at 04:04:27PM -0600, Warner Losh wrote: > On Thu, Apr 14, 2016 at 3:54 PM, Dmitry Morozovsky <marck@rinet.ru> wrote: >=20 > > 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? >=20 >=20 > You add CAM_NETFLIX_IOSCHED to your kernel config to enable it. Hmmm, > looking at the diff, perhaps I should add that to LINT. >=20 > In production, we use it for three things. First, our scheduler keeps a l= ot > more > statistics than the default one. These statistics are useful for us knowi= ng > 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. T= he > 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 t= hat > 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. Going on a tangent here, but related: As someone who is just barely stepping into the world of benchmarks and performance metrics, can you shed some light as to how you gained those metrics? I'd be extremely interested to learn. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXEBZzAAoJEGqEZY9SRW7uJl0P/2gIgto9LvTvKsF+cCC9zviA 0tdJUiZDQd5pYM5T2C/LW3bNjFebb/0gFrXrMXhxXzXIlseL5glYfdPe3rmiWLjl 9/TmaojeREhZWk406vVuB/ZAz82qG5aix+EltxrQp7ukdolEMajvm4DKM4K6Q0+t 2DdZ2YdtOnRGjPkcgHRYtzCzAfpOoCWPstohE8MLlWhrNl+RXOw6NB9tYxNjP0IB zPYz/9R4/DPhf3hRxLSr1OkIuhA1pqR0eN7Q9UpACYfAkrCz4KMGBgO1tU2e/26B Pqk+vGQO1OwLdNP4WHwqueC3gfbqB9yyJ1isDSlYaYhITFJynVw9MltLPXI3hNu0 lD8anIdQP9LhAeIJHFLZrYYq3zQ9Nl4zBWv93TCKHvyeot220wLcgBkXJx5Os9ko /Y8+YNeDogb/FI5+kwTPze5Rue+2Z/FnTpC77gvEkvF/AaaMtct9jDNL9DjYjHni 5YmgLzOaILrDET/BeV6jdNNcX/QMfIhfyXj0vYOfmd48+Aq0RgWG9N/pDGW8Wyla /Z7KZZAppxEwpQCVyw8TxCUTBLKMUhC8057jqcf83F/pBfRI6PrutwRAZG6qhfEp An6AlqxdUXpwVlHazDiCm6wGzClbnH+qV+8up1RNyvHdLCqJMYmXMCTZYOrqucnz pXENn6K4otp0rHrtwSUO =oDfk -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160414221517.GA66711>