[Devel] [PATCH RH7 10/10] blk-wbt: increase maximum queue depth to increase performance of writes

[Pavel Tikhomirov]

With wbt patches on simple test:

  #!/bin/bash
  rm -rf /my/filetree
  echo 3 > /proc/sys/vm/drop_caches
  sync

  time tar -xzf /my/filetree.zip -C /my
  time sync

we have a performance degradation of ~20-50% of last sync.

That looks connected with the fact that SATA devices always have a small
queue depth (request_queue->queue_depth == 31) and thus wbt is limiting
the maximum number of inflight write requests depending on the prioryty
with 8/16/23 (low to high), all extra writes just sleep waiting for
previous writes to complete.

But if more write requests given to the device driver, elevator
algorithm should give a better performance than if we only give them by
small portions, and before wbt we gave as much writes as we could.

The whole point of wbt is in scaling these three limits making them
bigger if we have only writes and making them lower if some reads want
to be processed.

So we increase the maximum from x3/4 of device queue size to x8. These
should improve writes performance when where are no concurrent reads.
These increase of "wb_..." limits makes reads latency decrease as now
wbt should scale_down several times when detecting read requests.

https://jira.sw.ru/browse/PSBM-96243

Signed-off-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
---
 block/blk-wbt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 7278466360b2..554f4ee970c7 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -227,7 +227,7 @@ static bool calc_wb_limits(struct rq_wb *rwb)
 		if (rwb->scale_step > 0)
 			depth = 1 + ((depth - 1) >> min(31, rwb->scale_step));
 		else if (rwb->scale_step < 0) {
-			unsigned int maxd = 3 * rwb->queue_depth / 4;
+			unsigned int maxd = 8 * rwb->queue_depth;
 
 			depth = 1 + ((depth - 1) << -rwb->scale_step);
 			if (depth > maxd) {
-- 
2.21.0