bcache: comment on direct access to bvec table

[linux.git] / drivers / md / bcache / util.c

diff --git a/drivers/md/bcache/util.c b/drivers/md/bcache/util.c
index 176d3c2ef5f5cf8b69ed425c504a204ca520dffb..61813d23001543932b05857b6f9143be908242b4 100644 (file)
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -232,8 +232,14 @@ uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done)
 
        d->next += div_u64(done * NSEC_PER_SEC, d->rate);
 
-       if (time_before64(now + NSEC_PER_SEC, d->next))
-               d->next = now + NSEC_PER_SEC;
+       /* Bound the time.  Don't let us fall further than 2 seconds behind
+        * (this prevents unnecessary backlog that would make it impossible
+        * to catch up).  If we're ahead of the desired writeback rate,
+        * don't let us sleep more than 2.5 seconds (so we can notice/respond
+        * if the control system tells us to speed up!).
+        */
+       if (time_before64(now + NSEC_PER_SEC * 5LLU / 2LLU, d->next))
+               d->next = now + NSEC_PER_SEC * 5LLU / 2LLU;
 
        if (time_after64(now - NSEC_PER_SEC * 2, d->next))
                d->next = now - NSEC_PER_SEC * 2;
@@ -243,6 +249,13 @@ uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done)
                : 0;
 }
 
+/*
+ * Generally it isn't good to access .bi_io_vec and .bi_vcnt directly,
+ * the preferred way is bio_add_page, but in this case, bch_bio_map()
+ * supposes that the bvec table is empty, so it is safe to access
+ * .bi_vcnt & .bi_io_vec in this way even after multipage bvec is
+ * supported.
+ */
 void bch_bio_map(struct bio *bio, void *base)
 {
        size_t size = bio->bi_iter.bi_size;