Date: Fri, 15 Apr 2016 11:33:01 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Heads up Message-ID: <CAJ-VmonpfMhwk-1eqYQJs0pJWMqC-oqhVwV-VeXBuQEDrdfBFw@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 15 April 2016 at 09:26, 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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonpfMhwk-1eqYQJs0pJWMqC-oqhVwV-VeXBuQEDrdfBFw>