linux-kernel - Re: [PATCH]cfq-iosched: don't take requests with long distence as close

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <x49hbqy3s3m.fsf@segfault.boston.devel.redhat.com>
Date:	Thu, 07 Jan 2010 09:30:21 -0500
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Corrado Zoccolo <czoccolo@...il.com>
Cc:	Shaohua Li <shaohua.li@...el.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"jens.axboe\@oracle.com" <jens.axboe@...cle.com>,
	"Zhang\, Yanmin" <yanmin.zhang@...el.com>
Subject: Re: [PATCH]cfq-iosched: don't take requests with long distence as  close

Corrado Zoccolo <czoccolo@...il.com> writes:

> On Tue, Jan 5, 2010 at 10:16 PM, Jeff Moyer <jmoyer@...hat.com> wrote:
>>
>> For now, I'm leaning towards asking Jens to revert this.  It may still
>> be worth making sure that we don't merge a seeky queue with a non-seeky
>> queue.  I have a patch for that if folks are interested.
> Jeff, can you send this patch to Yanmin, that is investigating a
> regression apparently caused by excessive queue merge?
>
> http://lkml.org/lkml/2010/1/4/194


You first have to back out Shaohua's patch, then apply this one.

Cheers,
Jeff

cfq-iosched: don't allow merging with seeky queues

Shaohua Li noticed that cfq currently can merge with seeky queues, which
causes unwanted merge/unmerge activity.  We already know that the
cur_cfqq is not seeky, so this patch just makes sure that the non-seeky
queue is not merged with a seeky one.

Signed-off-by: Jeff Moyer <jmoyer@...hat.com>

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 8df4fe5..3db9050 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1677,6 +1677,10 @@ static inline int cfq_rq_close(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 	return cfq_dist_from_last(cfqd, rq) <= sdist;
 }
 
+/*
+ * Search for a cfqq that is issuing non-seeky I/Os within the seek
+ * mean of the current cfqq.
+ */
 static struct cfq_queue *cfqq_close(struct cfq_data *cfqd,
 				    struct cfq_queue *cur_cfqq)
 {
@@ -1701,7 +1705,14 @@ static struct cfq_queue *cfqq_close(struct cfq_data *cfqd,
 	 * will contain the closest sector.
 	 */
 	__cfqq = rb_entry(parent, struct cfq_queue, p_node);
-	if (cfq_rq_close(cfqd, cur_cfqq, __cfqq->next_rq))
+	/*
+	 * If the cfqq does not have enough seek samples, assume it is
+	 * sequential until proven otherwise.  If it is assumed that the
+	 * queue is seeky first, then the close cooperator detection logic
+	 * may never trigger as one queue strays further from the other(s).
+	 */
+	if (cfq_rq_close(cfqd, cur_cfqq, __cfqq->next_rq) &&
+	    (!sample_valid(__cfqq->seek_samples) || !CFQQ_SEEKY(__cfqq)))
 		return __cfqq;
 
 	if (blk_rq_pos(__cfqq->next_rq) < sector)
@@ -1712,7 +1723,8 @@ static struct cfq_queue *cfqq_close(struct cfq_data *cfqd,
 		return NULL;
 
 	__cfqq = rb_entry(node, struct cfq_queue, p_node);
-	if (cfq_rq_close(cfqd, cur_cfqq, __cfqq->next_rq))
+	if (cfq_rq_close(cfqd, cur_cfqq, __cfqq->next_rq) &&
+	    (!sample_valid(__cfqq->seek_samples) || !CFQQ_SEEKY(__cfqq)))
 		return __cfqq;
 
 	return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/