Heads up

[Adrian Chadd]

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.




-adrian