From owner-freebsd-current@freebsd.org Fri Apr 15 16:34:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60C90AEE7FA for ; Fri, 15 Apr 2016 16:34:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A1C21162 for ; Fri, 15 Apr 2016 16:34:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x242.google.com with SMTP id fn8so3573138igb.2 for ; Fri, 15 Apr 2016 09:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=/WJTYdoS1Ptpa4XlktHBR2r5mt3Ew7SJnfYDwic46Uc=; b=Teopm+wwk20/EQGNjcdwNdLJ9jZSUwmvEg1rdW3iuuvK7evM3r7HQ0pDQahpNOzDrx ZbOoOZYvf9qeDQGa5uDQy4NWHB6LfstavyYJHY3kt7mFpYeHQ37r86DXSmi2+cz3moCE QZc7+LKEIIbXQgCp46k2Rql6gkaGZJYq1ckHyYhNS4qGMH5GIaXu1yRRDMj/oI2M4miw GqPZsIA7xTAErzYskVKuhlP+BM5BgTpfkP5/AbkiPcKjBWCgmPp3LI28BLfNvGLQwEFG XFf4UgNFhwRlhZgQcwcZbiTxKYMPzyqxHdTo0cXxOmPzVcg+1htlFrh+kHqBRVZvBgwV nSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/WJTYdoS1Ptpa4XlktHBR2r5mt3Ew7SJnfYDwic46Uc=; b=RlSXd5+Wqtb8u9vegKv4CKgllbE+CmjUb0Wc5ov+XM36J3NASolwpFjYFExka7IQsg yYCX9fq4Tm2QLXi5SDjCshY2K94HrUuMheYMdTwe8A+G4T7h53JHtBSwZQfIJzOSHEtA JUxvib1lwaqkVc8KTYE4ih9xASh1YA30jpRFRboS6d0w37imCNA22W8jMim3p9+J4UMt 9QKPhwvHHNIHxfTo4+b8X14L8Hcd23DPdedWDMZDPaNyOyePi6yvY/u7xczrRQ8a3xUD e7Uzfp7qfyceDtIPWAknig4Sc7D3ZWKrpgaxcf3fSeupGcPNPWdv/E+vazJpBtYFFeD/ IwZA== X-Gm-Message-State: AOPr4FVWutYxgkMkUElbYNc+VbqeZ2nsowSIXhQQvlfwaKmzMDQnCWGYTt/Rt2buvs6F71PjxdYOFpqoN8UaxQ== MIME-Version: 1.0 X-Received: by 10.50.77.107 with SMTP id r11mr6167303igw.91.1460738076469; Fri, 15 Apr 2016 09:34:36 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.8.133 with HTTP; Fri, 15 Apr 2016 09:34:36 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <57111629.6070606@freebsd.org> References: <57111629.6070606@freebsd.org> Date: Fri, 15 Apr 2016 10:34:36 -0600 X-Google-Sender-Auth: zrbwBFv-gFf7uX82O7t3dgjm6OQ Message-ID: Subject: Re: Heads up From: Warner Losh To: Allan Jude Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 16:34:37 -0000 On Fri, Apr 15, 2016 at 10:26 AM, Allan Jude 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 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 > >