From patchwork Mon Sep 10 20:49:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10594783 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 96E1B920 for ; Mon, 10 Sep 2018 20:49:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 83CE02932A for ; Mon, 10 Sep 2018 20:49:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 783C92933E; Mon, 10 Sep 2018 20:49:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DC9152932A for ; Mon, 10 Sep 2018 20:49:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726761AbeIKBp1 (ORCPT ); Mon, 10 Sep 2018 21:45:27 -0400 Received: from mail-qk1-f178.google.com ([209.85.222.178]:43667 "EHLO mail-qk1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbeIKBp1 (ORCPT ); Mon, 10 Sep 2018 21:45:27 -0400 Received: by mail-qk1-f178.google.com with SMTP id 130-v6so15363755qkd.10 for ; Mon, 10 Sep 2018 13:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id; bh=TvuLjkW+HYeyvw6T+2U+l0rv2X/EgN2eIY6tEI7gSfE=; b=u7dRqII9CWAToMRryvfb9Bq8P7mcEeXjv4PUR1n/lIe9lDkKhZnW6Ou8yE/YudlpbN VqhBK9m0KaCuqqYHXQ5CmzhSZIJF0xJjw+vhEi/aWwkITBYj8Z1pJ101saUVO78YTiab Z+WvWaqQO6IvZu1ng3Rv3DWZbtVvuJX6wUuY0y8HjvtojVAft1XD/gGcNy2rOypbCi73 3AIlB48Qt6/UFfj9BXahC0Dk861a/9GjnymBGHtmmFvPQLGUWOtyAq32Sh7vb5z/fh2n ow2fxVsv8oQvKMpYnrj4r/IXBeVGIuL0+N3ZrnBzipVppH6IytPENfwiSBvRXNuAx8ln mzEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id; bh=TvuLjkW+HYeyvw6T+2U+l0rv2X/EgN2eIY6tEI7gSfE=; b=p/kL3ROR2oS0Ckjr+GkORCpc1zEs5HD80sbf8XFjskQsuSbTZf77jjt2I487kj9yEE iVPpA0H67NT8v/33o5DbHu7bgypFQwGugxAC46gkHXNOHAiE80q1pu8TO8nXVBZE4kdH hc3aLive8QEVIz3hdw5IP1zZgZiBhIzl60+Mih1V7lNfHt9Td6AuHkGhR8CQ3WFO8b3s 6iWl7A+9NOQumNxdnEhruMJ7rFoR0HtKLsyNfutT+xbuqjBbUhA5BLZeOxjQZYwp+xWi awumbqxxUE71qJjiSgELC7YteUdHVZNAYkqwLn6qddpeB2ltk+s0EIXiXUith8xtVrA0 cYWQ== X-Gm-Message-State: APzg51BVDGQdwU2LGB2s6o1Y07egO4a6zLCGJqQ/DUwv7NveRHFx1atv 6cKDTfJchOqhMRhmjv16900kyA== X-Google-Smtp-Source: ANB0VdbRj/T92XF58RvgMzUyh4TmSY3Jghs/o8OmswRahaq26wp6YIqPQgHDAu2CdShVPNNbS3meLA== X-Received: by 2002:a37:9c8d:: with SMTP id f135-v6mr16665494qke.98.1536612575037; Mon, 10 Sep 2018 13:49:35 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id k9-v6sm13489076qtk.2.2018.09.10.13.49.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Sep 2018 13:49:34 -0700 (PDT) From: Josef Bacik To: axboe@kernel.dk, kernel-team@fb.com, linux-block@vger.kernel.org Subject: [PATCH 0/6] blk-iolatency: Fixes and tweak the miss algo for ssds Date: Mon, 10 Sep 2018 16:49:26 -0400 Message-Id: <20180910204932.14323-1-josef@toxicpanda.com> X-Mailer: git-send-email 2.14.3 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Testing on ssd's with the current iolatency code wasn't working quite as well. This is mostly because ssd's don't behave like rotational drives, they are more spikey which means that using the average latency for IO wasn't very responsive until the drive was extremely over taxed. To deal with this I've reworked iolatency to use a p(90) based approach for ssd latencies. I originally intended to use this approach for both ssd's and rotational drives, but p(90) was too high of a bar to use. By the time we were exceeding p(90) things were already pretty bad. So to keep things simpler just use p(90) for ssd's since their latency targets tend to be orders of magnitude lower than rotational drives, and keep the average latency calculations for rotational drives. This testing also showed a few issues with blk-iolatency, so the preceding patches are all fixing issues we saw in testing. Using q->nr_requests instead of blk_queue_depth() is probably the most subtle and important change. We want to limit the IO's based on the number of outstanding requests we can have in the block layer, not necessarily how many we can have going to the device. So make this explicity by using nr_requests directly. These patches have been in production for a week on both our rotational and ssd tiers and everything is going smoothly. Thanks, Josef