Date: Fri, 15 Apr 2016 10:34:36 -0600 From: Warner Losh <imp@bsdimp.com> To: Allan Jude <allanjude@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Heads up Message-ID: <CANCZdfpXka9mJ0VibWMbHfgRXfzuZE5Lo3HOWYgNS-vmt0rqbg@mail.gmail.com> In-Reply-To: <57111629.6070606@freebsd.org> References: <CANCZdfpnYnVrvhNagYUT9RhAuC1AMCrxh=GCt8RKT0bqxuJybw@mail.gmail.com> <CAH7qZftspY=i5MaQ6sNg5L5XXBN7gfCuAMO-NZt=7Qp5zo6u_w@mail.gmail.com> <57111629.6070606@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 15, 2016 at 10:26 AM, Allan Jude <allanjude@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. > Yes. The I/O scheduler can do that. But it also does much more. It isn't limited to doing just that. > Most workflows, like a database on an SSD, will be the opposite, wanting > to prioritize writes over anything else. > It can also do this as well. You get to choose what I/O you want to prioritize, and what throttling, if any, you want to do. Future versions will also allow you to throttle X operations within some range depending on the Y metric for Z operation. It will likely introduce prioritization of I/O requests and deadline scheduling to complement the I/O back pressure work I'm doing right now on the upper layers of the I/O stack. Well, on the 'buf' side of the house, not the ZFS side. 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' While that was the first use of the scheduler, the scheduler itself is far more flexible than that. As committed, you'll need to tweak it even for that work load. That's why I'm resisting changing the name. It's name is fine. Warner > > > > On Thu, Apr 14, 2016 at 3:42 PM, Warner Losh <imp@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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpXka9mJ0VibWMbHfgRXfzuZE5Lo3HOWYgNS-vmt0rqbg>