From patchwork Fri Sep 28 17:45:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10620225 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 1A35F15E8 for ; Fri, 28 Sep 2018 17:45:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 062CD2BEB6 for ; Fri, 28 Sep 2018 17:45:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EDA242BF68; Fri, 28 Sep 2018 17:45: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 6D01D2BEB6 for ; Fri, 28 Sep 2018 17:45:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726112AbeI2AKi (ORCPT ); Fri, 28 Sep 2018 20:10:38 -0400 Received: from mail-qt1-f180.google.com ([209.85.160.180]:44839 "EHLO mail-qt1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726100AbeI2AKi (ORCPT ); Fri, 28 Sep 2018 20:10:38 -0400 Received: by mail-qt1-f180.google.com with SMTP id c56-v6so2634975qtd.11 for ; Fri, 28 Sep 2018 10:45:47 -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=6JJErauDgxsvResa7bQQ2MepAjruFGmOT3Z1ur1zVws=; b=ofnau5PeDviz8yXgALRPXqmywOnhr1CtzsQEL/QTguoYC7UTW8BlqNgkT1uOsXlZ02 J3SS6UtIhitMw7a1wknlb+sS2CQ4imn5lpNEFBG3nGDWI9a52OwVcS6H0br2oadW4067 dBW6zRH5f70k8KkfuNT5NvJdV/uzDIIBUHxQnFlos1rAVfsBt0OHcpLZGq8k9Hr+C/E2 TShuDYUiuTv7blGPp4VzhIVX9psyt9CHtOJuI/9WC5qtKPoZ1MlurwNKcBtuONqV31y7 0gMikafBPESau9L4rclaLLb3++6IJA/WFYvebj6MSzD6BNgGtsru1BjPrBnKcD7jNbQG GloA== 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=6JJErauDgxsvResa7bQQ2MepAjruFGmOT3Z1ur1zVws=; b=GKpbM9vFF9CELsw6yDYw3m+dgkX+FG48zs4AuJIyWUPKK/EYLHmQsunBAEUoGhyJRL wIkNFAQKkaZ47gCCblntdH5fN3otPY4G4ADD12RLw6yYiH5nS7GC/f5tWu1/z0WbaSRc t9NV36elbFz/QEfiv9z1wXnkQaqTSaCIKv8rsLgzc8P9VsY0Oa9XmRjxrvP7jQtPJ3xW jduqi8jt3wwIehPTbrQGSf625yvF8LM+zWJuZTjIy/6gAsPEQ+x6TPVOdDmIVnpT0wzr qGqfYdJH2tEqqgoDkuv6OuxIkh7P0QICjiYANMoY35+eC3R3erUsQDAjBFJ4+bOKY2/C xqzQ== X-Gm-Message-State: ABuFfoiM32qfE+/nQ2czqABvwsd98WKHRDIQilR1MxHsCUiJsoXSod4E /zynEi47384eGuzkOV4iFrZ6uA== X-Google-Smtp-Source: ACcGV62y4yPLaaadFQ2+tTEK+xgYlMaFlfmjVOqGB2/VuJfhrt7l9swku06oUbguFYtSt9FMV/Xbpg== X-Received: by 2002:ac8:36bd:: with SMTP id a58-v6mr12692679qtc.236.1538156746809; Fri, 28 Sep 2018 10:45:46 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id 62-v6sm3487582qkw.72.2018.09.28.10.45.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Sep 2018 10:45:45 -0700 (PDT) From: Josef Bacik To: axboe@kernel.dk, linux-block@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 0/5][v2] blk-iolatency: Fixes and tweak the miss algo for ssds Date: Fri, 28 Sep 2018 13:45:38 -0400 Message-Id: <20180928174543.28486-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 v1->v2: - rebased onto a recent for-4.20/block branch - dropped the changed variable cleanup. -- Original message -- 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