svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci

[Dmitry Morozovsky]

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 at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------