Thread (21 messages) 21 messages, 4 authors, 2022-12-21

Re: [PATCH V10 1/8] block, bfq: split sync bfq_queues on a per-actuator basis

From: Paolo Valente <hidden>
Date: 2022-12-21 10:32:17
Also in: lkml

Il giorno 21 dic 2022, alle ore 11:13, Paolo Valente [off-list ref] ha scritto:


quoted
Il giorno 21 dic 2022, alle ore 01:50, Damien Le Moal [off-list ref] ha scritto:

On 2022/12/20 22:10, Paolo Valente wrote:
quoted
quoted
quoted
-	/*
-	 * Does queue (or any parent entity) exceed number of requests that
-	 * should be available to it? Heavily limit depth so that it cannot
-	 * consume more available requests and thus starve other entities.
-	 */
-	if (bfqq && bfqq_request_over_limit(bfqq, limit))
-		depth = 1;
+	for (act_idx = 0; act_idx < bfqd->num_actuators; act_idx++) {
+		struct bfq_queue *bfqq =
+			bic ? bic_to_bfqq(bic, op_is_sync(opf), act_idx) : NULL;
Commented already: why not add a "if (!bfqq) return NULL;" in
bic_to_bfqq() ?
You have probably missed my reply on this.  The problem is that your
proposal would improve code (only) here, but it would entail the above
control for all the other invocations, for which it is useless :(
But then you have *a lot* of "if (bfqd)" tests that are useless elsewhere since
bic_to_bfqq() never returns NULL.
I'm probably misunderstanding your point, sorry.  Could you point me
to one of the places where there is the useless control that would go
away if we add your proposed control inside bic_to_bfqq?
You had already done that in a following email, sorry.  I have replied
to that email of yours.

Thanks,
Paolo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help