Update BFQ to v8r12

3 files changed, 489 insertions, 5 deletions

diff --git a/.SRCINFO b/.SRCINFO
index 2f4d641b6944..8de7235f1045 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,6 +1,6 @@
 pkgbase = linux-bfq
 	pkgver = 4.11.8
-	pkgrel = 1
+	pkgrel = 2
 	url = http://algo.ing.unimo.it
 	arch = i686
 	arch = x86_64
@@ -22,6 +22,7 @@ pkgbase = linux-bfq
 	source = config.x86_64
 	source = 90-linux.hook
 	source = linux.preset
+	source = 0005-BFQ-update-to-v8r12.patch
 	validpgpkeys = ABAF11C65A2970B130ABE3C479BE3E4300411886
 	validpgpkeys = 647F28654894E3BD457199BE38DBBDC86092693E
 	sha512sums = 6610eed97ffb7207c71771198c36179b8244ace7222bebb109507720e26c5f17d918079a56d5febdd8605844d67fb2df0ebe910fa2f2f53690daf6e2a8ad09c3
@@ -37,6 +38,7 @@ pkgbase = linux-bfq
 	sha512sums = 57addf780fc68d8e2914514e47d2edd27600cc0d1bf0c7d3786bc3e16ec9c6527eb8e9d95f156da8b77c11a53ac2a8f0d23360547a26350ebc3dca93721ebc42
 	sha512sums = d6faa67f3ef40052152254ae43fee031365d0b1524aa0718b659eb75afc21a3f79ea8d62d66ea311a800109bed545bc8f79e8752319cd378eef2cbd3a09aba22
 	sha512sums = 2dc6b0ba8f7dbf19d2446c5c5f1823587de89f4e28e9595937dd51a87755099656f2acec50e3e2546ea633ad1bfd1c722e0c2b91eef1d609103d8abdc0a7cbaf
+	sha512sums = b1f6306a27d7e25eb4ff3eb51cb1fe38b0ca035cff229537d1b9f68bdc25861f2fecdeeeb1582e34cd166ee4275e49e4c679247a4c36109b2dcd6d4fa9456d60
 
 pkgname = linux-bfq
 	pkgdesc = Linux Kernel and modules with the BFQ scheduler.
diff --git a/0005-BFQ-update-to-v8r12.patch b/0005-BFQ-update-to-v8r12.patch
new file mode 100644
index 000000000000..f4535cbb718b
--- /dev/null
+++ b/0005-BFQ-update-to-v8r12.patch
@@ -0,0 +1,481 @@
+From 493c15c90a12961dc3a61ac37ecf4c8839eb189e Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Thu, 4 May 2017 17:47:13 +0200
+Subject: [PATCH 1/5] block, bfq: update wr_busy_queues if needed on a queue
+ split
+
+This commit fixes a bug triggered by a non-trivial sequence of
+events. These events are briefly described in the next two
+paragraphs. The impatiens, or those who are familiar with queue
+merging and splitting, can jump directly to the last paragraph.
+
+On each I/O-request arrival for a shared bfq_queue, i.e., for a
+bfq_queue that is the result of the merge of two or more bfq_queues,
+BFQ checks whether the shared bfq_queue has become seeky (i.e., if too
+many random I/O requests have arrived for the bfq_queue; if the device
+is non rotational, then random requests must be also small for the
+bfq_queue to be tagged as seeky). If the shared bfq_queue is actually
+detected as seeky, then a split occurs: the bfq I/O context of the
+process that has issued the request is redirected from the shared
+bfq_queue to a new non-shared bfq_queue. As a degenerate case, if the
+shared bfq_queue actually happens to be shared only by one process
+(because of previous splits), then no new bfq_queue is created: the
+state of the shared bfq_queue is just changed from shared to non
+shared.
+
+Regardless of whether a brand new non-shared bfq_queue is created, or
+the pre-existing shared bfq_queue is just turned into a non-shared
+bfq_queue, several parameters of the non-shared bfq_queue are set
+(restored) to the original values they had when the bfq_queue
+associated with the bfq I/O context of the process (that has just
+issued an I/O request) was merged with the shared bfq_queue. One of
+these parameters is the weight-raising state.
+
+If, on the split of a shared bfq_queue,
+1) a pre-existing shared bfq_queue is turned into a non-shared
+bfq_queue;
+2) the previously shared bfq_queue happens to be busy;
+3) the weight-raising state of the previously shared bfq_queue happens
+to change;
+the number of weight-raised busy queues changes. The field
+wr_busy_queues must then be updated accordingly, but such an update
+was missing. This commit adds the missing update.
+
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+---
+ block/bfq-iosched.c | 47 +++++++++++++++++++++++++++++++++++++++--------
+ block/bfq-sched.c   |  9 +++++++--
+ 2 files changed, 46 insertions(+), 10 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index a56888ea9d94..5e8cbeab45a1 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -673,8 +673,12 @@ static unsigned int bfq_wr_duration(struct bfq_data *bfqd)
+ }
+ 
+ static void
+-bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_io_cq *bic)
++bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_data *bfqd,
++		      struct bfq_io_cq *bic, bool bfq_already_existing)
+ {
++	unsigned int old_wr_coeff;
++	bool busy = bfq_already_existing && bfq_bfqq_busy(bfqq);
++
+ 	if (bic->saved_idle_window)
+ 		bfq_mark_bfqq_idle_window(bfqq);
+ 	else
+@@ -685,6 +689,9 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_io_cq *bic)
+ 	else
+ 		bfq_clear_bfqq_IO_bound(bfqq);
+ 
++	if (unlikely(busy))
++		old_wr_coeff = bfqq->wr_coeff;
++
+ 	bfqq->wr_coeff = bic->saved_wr_coeff;
+ 	bfqq->wr_start_at_switch_to_srt = bic->saved_wr_start_at_switch_to_srt;
+ 	BUG_ON(time_is_after_jiffies(bfqq->wr_start_at_switch_to_srt));
+@@ -693,8 +700,8 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_io_cq *bic)
+ 	BUG_ON(time_is_after_jiffies(bfqq->last_wr_start_finish));
+ 
+ 	if (bfqq->wr_coeff > 1 && (bfq_bfqq_in_large_burst(bfqq) ||
+-	    time_is_before_jiffies(bfqq->last_wr_start_finish +
+-				   bfqq->wr_cur_max_time))) {
++				   time_is_before_jiffies(bfqq->last_wr_start_finish +
++							  bfqq->wr_cur_max_time))) {
+ 		bfq_log_bfqq(bfqq->bfqd, bfqq,
+ 			     "resume state: switching off wr (%lu + %lu < %lu)",
+ 			     bfqq->last_wr_start_finish, bfqq->wr_cur_max_time,
+@@ -702,8 +709,20 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_io_cq *bic)
+ 
+ 		bfqq->wr_coeff = 1;
+ 	}
++
+ 	/* make sure weight will be updated, however we got here */
+ 	bfqq->entity.prio_changed = 1;
++
++	if (likely(!busy))
++		return;
++
++	if (old_wr_coeff == 1 && bfqq->wr_coeff > 1) {
++		bfqd->wr_busy_queues++;
++		BUG_ON(bfqd->wr_busy_queues > bfqd->busy_queues);
++	} else if (old_wr_coeff > 1 && bfqq->wr_coeff == 1) {
++		bfqd->wr_busy_queues--;
++		BUG_ON(bfqd->wr_busy_queues < 0);
++	}
+ }
+ 
+ static int bfqq_process_refs(struct bfq_queue *bfqq)
+@@ -1450,6 +1469,7 @@ static void bfq_add_request(struct request *rq)
+ 			bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);
+ 
+ 			bfqd->wr_busy_queues++;
++			BUG_ON(bfqd->wr_busy_queues > bfqd->busy_queues);
+ 			bfqq->entity.prio_changed = 1;
+ 			bfq_log_bfqq(bfqd, bfqq,
+ 				     "non-idle wrais starting, "
+@@ -1689,8 +1709,10 @@ static void bfq_bfqq_end_wr(struct bfq_queue *bfqq)
+ {
+ 	BUG_ON(!bfqq);
+ 
+-	if (bfq_bfqq_busy(bfqq))
++	if (bfq_bfqq_busy(bfqq)) {
+ 		bfqq->bfqd->wr_busy_queues--;
++		BUG_ON(bfqq->bfqd->wr_busy_queues < 0);
++	}
+ 	bfqq->wr_coeff = 1;
+ 	bfqq->wr_cur_max_time = 0;
+ 	bfqq->last_wr_start_finish = jiffies;
+@@ -2069,8 +2091,11 @@ bfq_merge_bfqqs(struct bfq_data *bfqd, struct bfq_io_cq *bic,
+ 		new_bfqq->last_wr_start_finish = bfqq->last_wr_start_finish;
+ 		new_bfqq->wr_start_at_switch_to_srt =
+ 			bfqq->wr_start_at_switch_to_srt;
+-		if (bfq_bfqq_busy(new_bfqq))
++		if (bfq_bfqq_busy(new_bfqq)) {
+ 			bfqd->wr_busy_queues++;
++			BUG_ON(bfqd->wr_busy_queues > bfqd->busy_queues);
++		}
++
+ 		new_bfqq->entity.prio_changed = 1;
+ 		bfq_log_bfqq(bfqd, new_bfqq,
+ 			     "wr start after merge with %d, rais_max_time %u",
+@@ -2081,8 +2106,11 @@ bfq_merge_bfqqs(struct bfq_data *bfqd, struct bfq_io_cq *bic,
+ 	if (bfqq->wr_coeff > 1) { /* bfqq has given its wr to new_bfqq */
+ 		bfqq->wr_coeff = 1;
+ 		bfqq->entity.prio_changed = 1;
+-		if (bfq_bfqq_busy(bfqq))
++		if (bfq_bfqq_busy(bfqq)) {
+ 			bfqd->wr_busy_queues--;
++			BUG_ON(bfqd->wr_busy_queues < 0);
++		}
++
+ 	}
+ 
+ 	bfq_log_bfqq(bfqd, new_bfqq, "merge_bfqqs: wr_busy %d",
+@@ -4553,7 +4581,7 @@ static int bfq_set_request(struct request_queue *q, struct request *rq,
+ 	const int is_sync = rq_is_sync(rq);
+ 	struct bfq_queue *bfqq;
+ 	unsigned long flags;
+-	bool split = false;
++	bool bfqq_already_existing = false, split = false;
+ 
+ 	spin_lock_irqsave(q->queue_lock, flags);
+ 	bfq_check_ioprio_change(bic, bio);
+@@ -4613,6 +4641,8 @@ static int bfq_set_request(struct request_queue *q, struct request *rq,
+ 			split = true;
+ 			if (!bfqq)
+ 				goto new_queue;
++			else
++				bfqq_already_existing = true;
+ 		}
+ 	}
+ 
+@@ -4638,7 +4668,8 @@ static int bfq_set_request(struct request_queue *q, struct request *rq,
+ 			 * queue, restore the idle window and the possible
+ 			 * weight raising period.
+ 			 */
+-			bfq_bfqq_resume_state(bfqq, bic);
++			bfq_bfqq_resume_state(bfqq, bfqd, bic,
++					      bfqq_already_existing);
+ 		}
+ 	}
+ 
+diff --git a/block/bfq-sched.c b/block/bfq-sched.c
+index 1fde0702bfef..36fb773c0832 100644
+--- a/block/bfq-sched.c
++++ b/block/bfq-sched.c
+@@ -1988,8 +1988,10 @@ static void bfq_del_bfqq_busy(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+ 		bfq_weights_tree_remove(bfqd, &bfqq->entity,
+ 					&bfqd->queue_weights_tree);
+ 
+-	if (bfqq->wr_coeff > 1)
++	if (bfqq->wr_coeff > 1) {
+ 		bfqd->wr_busy_queues--;
++		BUG_ON(bfqd->wr_busy_queues < 0);
++	}
+ 
+ 	bfqg_stats_update_dequeue(bfqq_group(bfqq));
+ 
+@@ -2018,6 +2020,9 @@ static void bfq_add_bfqq_busy(struct bfq_data *bfqd, struct bfq_queue *bfqq)
+ 			bfq_weights_tree_add(bfqd, &bfqq->entity,
+ 					     &bfqd->queue_weights_tree);
+ 
+-	if (bfqq->wr_coeff > 1)
++	if (bfqq->wr_coeff > 1) {
+ 		bfqd->wr_busy_queues++;
++		BUG_ON(bfqd->wr_busy_queues > bfqd->busy_queues);
++	}
++
+ }
+
+From 69373c8ac58080b60ca461689db6afb200d962e2 Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Tue, 9 May 2017 12:52:16 +0200
+Subject: [PATCH 2/5] block, bfq: stress that low_latency must be off to get
+ max throughput
+
+The introduction of the BFQ and Kyber I/O schedulers has triggered a
+new wave of I/O benchmarks. Unfortunately, comments and discussions on
+these benchmarks confirm that there is still little awareness that it
+is very hard to achieve, at the same time, a low latency and a high
+throughput. In particular, virtually all benchmarks measure
+throughput, or throughput-related figures of merit, but, for BFQ, they
+use the scheduler in its default configuration. This configuration is
+geared, instead, toward a low latency. This is evidently a sign that
+BFQ documentation is still too unclear on this important aspect. This
+commit addresses this issue by stressing how BFQ configuration must be
+(easily) changed if the only goal is maximum throughput.
+
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+---
+ Documentation/block/bfq-iosched.txt | 17 ++++++++++++++++-
+ block/bfq-iosched.c                 |  5 +++++
+ 2 files changed, 21 insertions(+), 1 deletion(-)
+
+diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt
+index 13b5248eba7e..0539e87962ed 100644
+--- a/Documentation/block/bfq-iosched.txt
++++ b/Documentation/block/bfq-iosched.txt
+@@ -11,6 +11,13 @@ controllers), BFQ's main features are:
+   groups (switching back to time distribution when needed to keep
+   throughput high).
+ 
++In its default configuration, BFQ privileges latency over
++throughput. So, when needed for achieving a lower latency, BFQ builds
++schedules that may lead to a lower throughput. If your main or only
++goal, for a given device, is to achieve the maximum-possible
++throughput at all times, then do switch off all low-latency heuristics
++for that device, by setting low_latency to 0. Full details in Section 3.
++
+ On average CPUs, the current version of BFQ can handle devices
+ performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a
+ reference, 30-50 KIOPS correspond to very high bandwidths with
+@@ -374,11 +381,19 @@ default, low latency mode is enabled. If enabled, interactive and soft
+ real-time applications are privileged and experience a lower latency,
+ as explained in more detail in the description of how BFQ works.
+ 
+-DO NOT enable this mode if you need full control on bandwidth
++DISABLE this mode if you need full control on bandwidth
+ distribution. In fact, if it is enabled, then BFQ automatically
+ increases the bandwidth share of privileged applications, as the main
+ means to guarantee a lower latency to them.
+ 
++In addition, as already highlighted at the beginning of this document,
++DISABLE this mode if your only goal is to achieve a high throughput.
++In fact, privileging the I/O of some application over the rest may
++entail a lower throughput. To achieve the highest-possible throughput
++on a non-rotational device, setting slice_idle to 0 may be needed too
++(at the cost of giving up any strong guarantee on fairness and low
++latency).
++
+ timeout_sync
+ ------------
+ 
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index 5e8cbeab45a1..cdf608e76048 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -36,6 +36,11 @@
+  * boost the throughput), and yet guarantee a low latency to
+  * interactive and soft real-time applications.
+  *
++ * NOTE: if the main or only goal, with a given device, is to achieve
++ * the maximum-possible throughput at all times, then do switch off
++ * all low-latency heuristics for that device, by setting low_latency
++ * to 0.
++ *
+  * BFQ is described in [1], where also a reference to the initial, more
+  * theoretical paper on BFQ can be found. The interested reader can find
+  * in the latter paper full details on the main algorithm, as well as
+
+From eb93d3e00badadb619cc8f62c1c04d1bf61e2890 Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Fri, 12 May 2017 10:19:52 +0200
+Subject: [PATCH 3/5] Fix commit "don't dereference bic before null checking
+ it"
+
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+---
+ block/bfq-iosched.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index cdf608e76048..c98dff9637c0 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -4589,7 +4589,6 @@ static int bfq_set_request(struct request_queue *q, struct request *rq,
+ 	bool bfqq_already_existing = false, split = false;
+ 
+ 	spin_lock_irqsave(q->queue_lock, flags);
+-	bfq_check_ioprio_change(bic, bio);
+ 
+ 	if (!bic)
+ 		goto queue_fail;
+
+From 8a119d7f3e592372a52d87093b2b4eb90330f055 Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Wed, 14 Jun 2017 15:35:44 +0200
+Subject: [PATCH 4/5] block, bfq: don't change ioprio class for a bfq_queue on
+ a service tree
+
+On each deactivation or re-scheduling (after being served) of a
+bfq_queue, BFQ invokes the function __bfq_entity_update_weight_prio(),
+to perform pending updates of ioprio, weight and ioprio class for the
+bfq_queue. BFQ also invokes this function on I/O-request dispatches,
+to raise or lower weights more quickly when needed, thereby improving
+latency. However, the entity representing the bfq_queue may be on the
+active (sub)tree of a service tree when this happens, and, although
+with a very low probability, the bfq_queue may happen to also have a
+pending change of its ioprio class. If both conditions hold when
+__bfq_entity_update_weight_prio() is invoked, then the entity moves to
+a sort of hybrid state: the new service tree for the entity, as
+returned by bfq_entity_service_tree(), differs from service tree on
+which the entity still is. The functions that handle activations and
+deactivations of entities do not cope with such a hybrid state (and
+would need to become more complex to cope).
+
+This commit addresses this issue by just making
+__bfq_entity_update_weight_prio() not perform also a possible pending
+change of ioprio class, when invoked on an I/O-request dispatch for a
+bfq_queue. Such a change is thus postponed to when
+__bfq_entity_update_weight_prio() is invoked on deactivation or
+re-scheduling of the bfq_queue.
+
+Reported-by: Marco Piazza <mpiazza@gmail.com>
+Reported-by: Laurentiu Nicola <lnicola@dend.ro>
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+Tested-by: Marco Piazza <mpiazza@gmail.com>
+---
+ block/bfq-iosched.c | 14 ++++++++++----
+ block/bfq-sched.c   | 38 ++++++++++++++++++++++++++++++++++----
+ 2 files changed, 44 insertions(+), 8 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index c98dff9637c0..c390711ea523 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -3689,11 +3689,17 @@ static void bfq_update_wr_data(struct bfq_data *bfqd, struct bfq_queue *bfqq)
+ 			}
+ 		}
+ 	}
+-	/* Update weight both if it must be raised and if it must be lowered */
++	/*
++	 * To improve latency (for this or other queues), immediately
++	 * update weight both if it must be raised and if it must be
++	 * lowered. Since, entity may be on some active tree here, and
++	 * might have a pending change of its ioprio class, invoke
++	 * next function with the last parameter unset (see the
++	 * comments on the function).
++	 */
+ 	if ((entity->weight > entity->orig_weight) != (bfqq->wr_coeff > 1))
+-		__bfq_entity_update_weight_prio(
+-			bfq_entity_service_tree(entity),
+-			entity);
++		__bfq_entity_update_weight_prio(bfq_entity_service_tree(entity),
++						entity, false);
+ }
+ 
+ /*
+diff --git a/block/bfq-sched.c b/block/bfq-sched.c
+index 36fb773c0832..d9a107dadc6d 100644
+--- a/block/bfq-sched.c
++++ b/block/bfq-sched.c
+@@ -766,9 +766,28 @@ static void bfq_forget_idle(struct bfq_service_tree *st)
+ 		bfq_put_idle_entity(st, first_idle);
+ }
+ 
++/*
++ * Update weight and priority of entity. If update_class_too is true,
++ * then update the ioprio_class of entity too.
++ *
++ * The reason why the update of ioprio_class is controlled through the
++ * last parameter is as follows. Changing the ioprio class of an
++ * entity implies changing the destination service trees for that
++ * entity. If such a change occurred when the entity is already on one
++ * of the service trees for its previous class, then the state of the
++ * entity would become more complex: none of the new possible service
++ * trees for the entity, according to bfq_entity_service_tree(), would
++ * match any of the possible service trees on which the entity
++ * is. Complex operations involving these trees, such as entity
++ * activations and deactivations, should take into account this
++ * additional complexity.  To avoid this issue, this function is
++ * invoked with update_class_too unset in the points in the code where
++ * entity may happen to be on some tree.
++ */
+ static struct bfq_service_tree *
+ __bfq_entity_update_weight_prio(struct bfq_service_tree *old_st,
+-			 struct bfq_entity *entity)
++				struct bfq_entity *entity,
++				bool update_class_too)
+ {
+ 	struct bfq_service_tree *new_st = old_st;
+ 
+@@ -813,9 +832,15 @@ __bfq_entity_update_weight_prio(struct bfq_service_tree *old_st,
+ 				  bfq_weight_to_ioprio(entity->orig_weight);
+ 		}
+ 
+-		if (bfqq)
++		if (bfqq && update_class_too)
+ 			bfqq->ioprio_class = bfqq->new_ioprio_class;
+-		entity->prio_changed = 0;
++
++		/*
++		 * Reset prio_changed only if the ioprio_class change
++		 * is not pending any longer.
++		 */
++		if (!bfqq || bfqq->ioprio_class == bfqq->new_ioprio_class)
++			entity->prio_changed = 0;
+ 
+ 		/*
+ 		 * NOTE: here we may be changing the weight too early,
+@@ -964,7 +989,12 @@ static void bfq_update_fin_time_enqueue(struct bfq_entity *entity,
+ 	struct bfq_queue *bfqq = bfq_entity_to_bfqq(entity);
+ 	struct bfq_sched_data *sd = entity->sched_data;
+ 
+-	st = __bfq_entity_update_weight_prio(st, entity);
++	/*
++	 * When this function is invoked, entity is not in any service
++	 * tree, then it is safe to invoke next function with the last
++	 * parameter set (see the comments on the function).
++	 */
++	st = __bfq_entity_update_weight_prio(st, entity, true);
+ 	bfq_calc_finish(entity, entity->budget);
+ 
+ 	/*
+
+From 2024487bd20c823bb5f96fe7ffbccf136628a2f7 Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Mon, 3 Jul 2017 22:00:29 +0200
+Subject: [PATCH 5/5] BFQ-v8r12
+
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+---
+ block/bfq-iosched.c | 2 +-
+ block/bfq.h         | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index c390711ea523..ea92c7461b89 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -5300,7 +5300,7 @@ static struct blkcg_policy blkcg_policy_bfq = {
+ static int __init bfq_init(void)
+ {
+ 	int ret;
+-	char msg[60] = "BFQ I/O-scheduler: v8r11";
++	char msg[60] = "BFQ I/O-scheduler: v8r12";
+ 
+ #ifdef CONFIG_BFQ_GROUP_IOSCHED
+ 	ret = blkcg_policy_register(&blkcg_policy_bfq);
+diff --git a/block/bfq.h b/block/bfq.h
+index 5f08990be66e..fe7816832035 100644
+--- a/block/bfq.h
++++ b/block/bfq.h
+@@ -1,5 +1,5 @@
+ /*
+- * BFQ v8r11 for 4.11.0: data structures and common functions prototypes.
++ * BFQ v8r12 for 4.11.0: data structures and common functions prototypes.
+  *
+  * Based on ideas and code from CFQ:
+  * Copyright (C) 2003 Jens Axboe <axboe@kernel.dk>
diff --git a/PKGBUILD b/PKGBUILD
index 25d2745b8b67..3d0ad8797ab2 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -52,7 +52,7 @@ pkgbase=linux-bfq
 # pkgname=('linux-bfq' 'linux-bfq-headers' 'linux-bfq-docs')
 _srcname=linux-4.11
 pkgver=4.11.8
-pkgrel=1
+pkgrel=2
 arch=('i686' 'x86_64')
 url="http://algo.ing.unimo.it"
 license=('GPL2')
@@ -80,7 +80,7 @@ source=("http://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.xz"
          # standard config files for mkinitcpio ramdisk
         'linux.preset'
         # patches from https://github.com/linusw/linux-bfq/commits/bfq-v8
-        )
+        '0005-BFQ-update-to-v8r12.patch')
 
 _kernelname=${pkgbase#linux} 
 
@@ -93,7 +93,7 @@ prepare() {
 
     ### Patch source with BFQ
         msg "Patching source with BFQ patches"
-        for p in "${srcdir}"/000{1,2,3,4}-*BFQ*.patch; do
+        for p in "${srcdir}"/000{1,2,3,4,5}-*BFQ*.patch; do
         msg " $p"
         patch -Np1 -i "$p"
         done
@@ -435,7 +435,8 @@ sha512sums=('6610eed97ffb7207c71771198c36179b8244ace7222bebb109507720e26c5f17d91
             '4030c799ee2fbf681aacd8396dab577162b9d34900c879c963ccb260fe40dc3fa1974cbe944ff1685cef2f0751528a3c5ba195c4ec6fca2b7b405e4f061f8e76'
             '57addf780fc68d8e2914514e47d2edd27600cc0d1bf0c7d3786bc3e16ec9c6527eb8e9d95f156da8b77c11a53ac2a8f0d23360547a26350ebc3dca93721ebc42'
             'd6faa67f3ef40052152254ae43fee031365d0b1524aa0718b659eb75afc21a3f79ea8d62d66ea311a800109bed545bc8f79e8752319cd378eef2cbd3a09aba22'
-            '2dc6b0ba8f7dbf19d2446c5c5f1823587de89f4e28e9595937dd51a87755099656f2acec50e3e2546ea633ad1bfd1c722e0c2b91eef1d609103d8abdc0a7cbaf')
+            '2dc6b0ba8f7dbf19d2446c5c5f1823587de89f4e28e9595937dd51a87755099656f2acec50e3e2546ea633ad1bfd1c722e0c2b91eef1d609103d8abdc0a7cbaf'
+            'b1f6306a27d7e25eb4ff3eb51cb1fe38b0ca035cff229537d1b9f68bdc25861f2fecdeeeb1582e34cd166ee4275e49e4c679247a4c36109b2dcd6d4fa9456d60')
             
 validpgpkeys=(
               'ABAF11C65A2970B130ABE3C479BE3E4300411886' # Linus Torvalds