Re: Heads up

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'

> 
> On Thu, Apr 14, 2016 at 3:42 PM, Warner Losh <imp_at_bsdimp.com> wrote:
> 
>> The CAM I/O scheduler has been committed to current. This work is described
>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
>> default scheduler doesn't change the default (old) behavior.
>>
>> One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
>> There are a few rogue drives that claim support for this feature, but
>> actually implement data corrupt instead of queued trims. The list of known
>> rogues is believed to be complete, but some caution is in order.
>>
>> Warner


-- 
Allan Jude