blk-wbt: account flush requests correctly
"Linux Kernel Mailing List" <[email protected]> Sat, 10 Feb 2018 22:21:28 +0000 (UTC)
| Newsgroups | gmane.linux.kernel.commits.head |
|---|---|
| Message-ID | <[email protected]> |
Web: https://git.kernel.org/torvalds/c/5235553d821433e1f4fa720fd025d2c4b7ee9994 Commit: 5235553d821433e1f4fa720fd025d2c4b7ee9994 Parent: 68c5735eaa5e680e701c9a2d1e3c7880bdf5ab66 Refname: refs/heads/master Author: Jens Axboe <[email protected]> AuthorDate: Mon Feb 5 13:16:56 2018 -0700 Committer: Jens Axboe <[email protected]> CommitDate: Tue Feb 6 14:14:03 2018 -0700 blk-wbt: account flush requests correctly Mikulas reported a workload that saw bad performance, and figured out what it was due to various other types of requests being accounted as reads. Flush requests, for instance. Due to the high latency of those, we heavily throttle the writes to keep the latencies in balance. But they really should be accounted as writes. Fix this by checking the exact type of the request. If it's a read, account as a read, if it's a write or a flush, account as a write. Any other request we disregard. Previously everything would have been mistakenly accounted as reads. Reported-by: Mikulas Patocka <[email protected]> Cc: [email protected] # v4.12+ Signed-off-by: Jens Axboe <[email protected]> --- block/blk-wbt.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index ae8de9780085..f92fc84b5e2c 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -697,7 +697,15 @@ u64 wbt_default_latency_nsec(struct request_queue *q) static int wbt_data_dir(const struct request *rq) { - return rq_data_dir(rq); + const int op = req_op(rq); + + if (op == REQ_OP_READ) + return READ; + else if (op == REQ_OP_WRITE || op == REQ_OP_FLUSH) + return WRITE; + + /* don't account */ + return -1; } int wbt_init(struct request_queue *q) -- To unsubscribe from this list: send the line "unsubscribe git-commits-head" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html