On 15 April 2016 at 09:26, Allan Jude <allanj...@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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to