From owner-freebsd-current@freebsd.org Fri Apr 15 18:33:02 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 8B192AEE4C9 for ; Fri, 15 Apr 2016 18:33:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 68434117B; Fri, 15 Apr 2016 18:33:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id g185so143021659ioa.2; Fri, 15 Apr 2016 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Wi7XCtaG2GwEI4KENwqb07Vijv26DzxXm480mpB9pZo=; b=Tpcvdt2a0qIdLnrobq8J+G0IeyZFy8WK2HCkdIFNz2qPzMLZFKhoeOkW3BsMKIeO3t A0mQZIu89UkZrB29vg6cDUoSbxTKnZ3m03yDL6usgpIII0K1+6s6xHwlSmEJp1PD6xoN swO7vNFQ031vq85nXwFrbZafs0nO6EBLhCTSFTQ5hGsQCOwymtMV1tFTTtdEoiCJYp2O 9VxQeIx4DAW6v/VsLncMaB/YO/3Erc7yfIaH4c4j2aF39CfbZRoOpVJvak4uT8jlBoJ8 KiXJcFAItxRtmSgGKj81D85CvXdSplzKZ3n7n99S5YYz23RAXaVTlSAH2TJibvsIQ3Cq 4VIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Wi7XCtaG2GwEI4KENwqb07Vijv26DzxXm480mpB9pZo=; b=Cff+gZqR6tlYk3AtgL7SQ9r9m2ZVQrgqI8M7cZYXrA4bsYjDzS4WO/KV3fq37gmRz+ thG1RJioQBfh4ikAF3yLBufz6bVjR9V4gVV6Xd5wCMAhUpXBjIIfa4I91+ePeUIaEJ0L 9DthhShPMlhjyCNGatxRhuJOTpqXwuQ9s/bKlnw0yp7b4JUbh0w8Y0qXDOSXBHgWM9SJ bNDeJL9oknobxbVNe9OAFq9pCZGDc/XSlmCfRk8goRKGyAp5IlD4v1c2EBdYTM/zeoR2 nLYP0ywrafy/mUSOLqcNvrm/FRVyllu4l8gmK5t7mOTl+E3mSK2P34tAZxJsWseYiYfO h0Gg== X-Gm-Message-State: AOPr4FXVeZIMNDgMnvjNwZgP/jh2MGu153ot/8gdsUkAhRpAqNq5AOl9os4Sp8su/3Fp7RB6NVTwSulK8/nE7w== MIME-Version: 1.0 X-Received: by 10.107.19.42 with SMTP id b42mr23804288ioj.75.1460745181757; Fri, 15 Apr 2016 11:33:01 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Fri, 15 Apr 2016 11:33:01 -0700 (PDT) In-Reply-To: <57111629.6070606@freebsd.org> References: <57111629.6070606@freebsd.org> Date: Fri, 15 Apr 2016 11:33:01 -0700 Message-ID: Subject: Re: Heads up From: Adrian Chadd To: Allan Jude Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 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 18:33:02 -0000 On 15 April 2016 at 09:26, 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. > > 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