From: Michael Lyle <mlyle@lyle.org>
To: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org
Cc: Michael Lyle <mlyle@lyle.org>
Subject: [for-416 PATCH] bcache: fix writeback target calc on large devices
Date: Wed, 27 Dec 2017 16:42:30 -0800 [thread overview]
Message-ID: <20171228004230.3295-1-mlyle@lyle.org> (raw)
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 <jack@douglastechnology.co.uk>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
---
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:
--
2.14.1
next reply other threads:[~2017-12-28 0:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-28 0:42 Michael Lyle [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-01-02 6:33 [for-416 PATCH] bcache: fix writeback target calc on large devices tang.junhui
2018-01-02 8:12 ` Michael Lyle
2018-01-02 9:25 tang.junhui
2018-01-02 17:04 ` Michael Lyle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171228004230.3295-1-mlyle@lyle.org \
--to=mlyle@lyle.org \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox