From owner-svn-src-all@freebsd.org Thu Apr 14 22:10:56 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DFDCADA2E2; Thu, 14 Apr 2016 22:10:56 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6EC71B1C; Thu, 14 Apr 2016 22:10:55 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id u3EMApSh099208; Fri, 15 Apr 2016 01:10:51 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 15 Apr 2016 01:10:51 +0300 (MSK) From: Dmitry Morozovsky To: Warner Losh cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers , Warner Losh Subject: Re: svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci In-Reply-To: Message-ID: References: <201604142147.u3ELlwYo052010@repo.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Fri, 15 Apr 2016 01:10:51 +0300 (MSK) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 22:10:56 -0000 Warner, On Thu, 14 Apr 2016, Warner Losh wrote: > 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. > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf Thank you again for clarifications! I'd reacted because we're @work possibly can see similar (while not nearly as comparable loads, of course!) patterns. > > 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. Great, at least it could be played with then! ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------