On 15 April 2016 at 09:26, Allan Jude <allanjude_at_freebsd.org> wrote: > On 2016-04-15 12:13, Maxim Sobolev wrote: >> Great, work Warner, thanks! Small note, though. The CAM_IOSCHED_NETFLIX >> seems like a quite poor name for a kernel option. IMHO there is no good >> reason for polluting it with the name of the company that sponsored the >> development. I don't think we have any precedents of doing this unless the >> option is related to a piece of hardware that the company makes, and it's >> not the case here. Apart from "coolness" factor as far as I understand that >> _NETFLIX suffix does not give any tangible benefit for anybody reading >> kernel config and trying to understand what this option actually does. >> CAM_IOSCHED_SSDNG or something would be better IMHO. Just my $0.02. >> >> -Max > > The tuning that CAM_IOCHED_NETFLIX does is not generally applicable to > all SSDs, it is very specific to netflix style workloads, where you want > to rate-limit writes to preserve low latency for reads. > > Most workflows, like a database on an SSD, will be the opposite, wanting > to prioritize writes over anything else. > > It is important to not give this scheduler a generic attractive name > that will cause people to use it without understanding what its purpose > is. The purpose is not 'better scheduling for SSDs', but rather > 'scheduling for a latency sensitive read-mostly workload while updating > a content library in the background' Actually, it would be really nice if it were adaptive, and I think Warners middle ground for SSDs is the best. Ie, watch how deep queues can get, and if we start seeing read throughput drop off, start backing off on writes. -adrianReceived on Fri Apr 15 2016 - 16:33:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC