From patchwork Thu Dec 28 00:42:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Lyle X-Patchwork-Id: 10134335 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BCBFF605B4 for ; Thu, 28 Dec 2017 00:43:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AD79A2C518 for ; Thu, 28 Dec 2017 00:43:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9F7132D1D1; Thu, 28 Dec 2017 00:43:23 +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=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 0F31D2C518 for ; Thu, 28 Dec 2017 00:43:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752639AbdL1AnI (ORCPT ); Wed, 27 Dec 2017 19:43:08 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:42561 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752016AbdL1AnH (ORCPT ); Wed, 27 Dec 2017 19:43:07 -0500 Received: by mail-pg0-f65.google.com with SMTP id q67so10094501pga.9 for ; Wed, 27 Dec 2017 16:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lyle-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=PVybcPSAY9aKVURYshdm2cn1Kwnq07mAPPgnGq6oWec=; b=v5nqaAo1kc6Bfwt/jKXK9X+I1fh3OiUoyYjz8vTmeRhSCbHA/w09SwnIQJz4vSpZxJ 7nAJ8iSYcvANZmPrR3UhqfUcGTwgfpWXiQcsNeleDPeIaqFxjbJagdlOzaAq0Xr2HDBM YJ2J60SIMkpXs6SyDkXLzU17LYZokRZUCDWWp4LwfbVZ/uuL1sFizJxCTSpAccO+Cs1T 0I/XpV2NjzxT5MUv+XMwaDSfurNbS1C8qrMXb3IO6daeSGtg8qGeAkzpo8DWup6P7RYD vDjqViiL5l6wAo5Q7+E9Cgq8YzZMNEmbdM60QCmEi0ZCAdQFNLCAQoC01JU5ibFddFbm 4ERA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=PVybcPSAY9aKVURYshdm2cn1Kwnq07mAPPgnGq6oWec=; b=m8SyCNQTfNj0LW4Sjp4tW1SlHbSga0Xy/0vi5XfmjSyr8T3vOQleHfIPATLFqzszwN rXs0zJpMqPgYIyMcGjOw+ie48ir9Ze+Rcep+Tdp9Tgfwmg+BiWuwA96R7THDHjvrm0w0 VnZH8QbImYGZNoLHrymrBOFnqSmG3X1CRZQWEoc2Hc72MCGcvclyxq2ZoH5hULBYkZ20 oosUHvk5fFj5BNNayWsnsuzOvenn8fJU7MWQ6zEX+CFeUUccv8gjZwaWZeJQ43nfUJMA +m0HQdps88dr97Tfw8YLNpMa4rX2bwiaLy2l5m3jA9p1eIFAynRk9mVT17J88d7O6bkS iWcw== X-Gm-Message-State: AKGB3mLG7U2CGmCbj502EqkgN9vwqNl8J146gS62O/eaW6q6z8fNs+R+ SP2GQzWfZJXuTXgehfSkbUbCyf5k X-Google-Smtp-Source: ACJfBouzpnNmKEPZobmI9LDKSC71gPigy7y/FauIeXTaf5EukH0ynKSei/EO+cdNO+rNI3/iL+BEFA== X-Received: by 10.99.117.65 with SMTP id f1mr11245086pgn.315.1514421786944; Wed, 27 Dec 2017 16:43:06 -0800 (PST) Received: from midnight.lan (2600-6c52-6200-383d-a0f8-4aea-fac9-9f39.dhcp6.chtrptr.net. [2600:6c52:6200:383d:a0f8:4aea:fac9:9f39]) by smtp.gmail.com with ESMTPSA id r13sm70536203pfl.157.2017.12.27.16.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 16:43:06 -0800 (PST) From: Michael Lyle To: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org Cc: Michael Lyle Subject: [for-416 PATCH] bcache: fix writeback target calc on large devices Date: Wed, 27 Dec 2017 16:42:30 -0800 Message-Id: <20171228004230.3295-1-mlyle@lyle.org> X-Mailer: git-send-email 2.14.1 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 Bcache needs to scale the dirty data in the cache over the multiple backing disks in order to calculate writeback rates for each. The previous code did this by multiplying the target number of dirty sectors by the backing device size, and expected it to fit into a uint64_t; this blows up on relatively small backing devices. The new approach figures out the bdev's share in 16384ths of the overall cached data. This is chosen to cope well when bdevs drastically vary in size and to ensure that bcache can cross the petabyte boundary for each backing device. Reported-by: Jack Douglas Signed-off-by: Michael Lyle --- drivers/md/bcache/writeback.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c index 56a37884ca8b..ddbbeec1f0ee 100644 --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -24,10 +24,23 @@ static void __update_writeback_rate(struct cached_dev *dc) struct cache_set *c = dc->disk.c; uint64_t cache_sectors = c->nbuckets * c->sb.bucket_size - bcache_flash_devs_sectors_dirty(c); + /* + * Unfortunately we don't know the exact share of dirty data for + * each backing device. Therefore, we need to infer the writeback + * for each disk based on its assumed proportion of dirty data. + * + * 16384 is chosen here as something that each backing device should + * be a reasonable fraction of the share, and not to blow up until + * individual backing devices are a petabyte. + */ + uint32_t bdev_share_per16k = + div64_u64(bdev_sectors(dc->bdev) << 14, + c->cached_dev_sectors); + uint64_t cache_dirty_target = div_u64(cache_sectors * dc->writeback_percent, 100); - int64_t target = div64_u64(cache_dirty_target * bdev_sectors(dc->bdev), - c->cached_dev_sectors); + + int64_t target = (cache_dirty_target * bdev_share_per16k) >> 14; /* * PI controller: