linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Ronald <intercommit@gmail.com>,
	Bart Van Assche <bart.vanassche@gmail.com>,
	Vladislav Bolkhovitin <vst@vlnb.net>,
	Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [RFC PATCH] Fix Readahead stalling by plugged device queues
Date: Wed, 10 Mar 2010 21:09:32 +0800	[thread overview]
Message-ID: <20100310130932.GB18509@localhost> (raw)
In-Reply-To: <4B979104.6010907@linux.vnet.ibm.com>

> --- linux.orig/mm/readahead.c
> +++ linux/mm/readahead.c
> @@ -188,8 +188,11 @@ __do_page_cache_readahead(struct address
>  	 * uptodate then the caller will launch readpage again, and
>  	 * will then handle the error.
>  	 */
> -	if (ret)
> +	if (ret) {
>  		read_pages(mapping, filp, &page_pool, ret);
> +		/* unplug backing dev to avoid latencies */
> +		blk_run_address_space(mapping);
> +	}

Christian, did you notice this commit for 2.6.33?

commit 65a80b4c61f5b5f6eb0f5669c8fb120893bfb388
Author: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
Date:   Thu Dec 17 15:27:26 2009 -0800

    readahead: add blk_run_backing_dev

--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -547,5 +547,17 @@ page_cache_async_readahead(struct address_space *mapping,
 
        /* do read-ahead */
        ondemand_readahead(mapping, ra, filp, true, offset, req_size);
+
+#ifdef CONFIG_BLOCK
+       /*
+        * Normally the current page is !uptodate and lock_page() will be
+        * immediately called to implicitly unplug the device. However this
+        * is not always true for RAID conifgurations, where data arrives
+        * not strictly in their submission order. In this case we need to
+        * explicitly kick off the IO.
+        */
+       if (PageUptodate(page))
+               blk_run_backing_dev(mapping->backing_dev_info, NULL);
+#endif
 }

It should at least improve performance between .32 and .33, because
once two readahead requests are merged into one single IO request,
the PageUptodate() will be true at next readahead, and hence
blk_run_backing_dev() get called to break out of the suboptimal
situation. 

Your patch does reduce the possible readahead submit latency to 0.

Is your workload a simple dd on a single disk? If so, it sounds like
something illogical hidden in the block layer.

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-03-10 13:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-10 12:31 [RFC PATCH] Fix Readahead stalling by plugged device queues Christian Ehrhardt
2010-03-10 13:09 ` Wu Fengguang [this message]
2010-03-10 14:31   ` Christian Ehrhardt
2010-03-11  1:45     ` Wu Fengguang
2010-03-11  9:58       ` Christian Ehrhardt
2010-03-11 13:29         ` Wu Fengguang
2010-03-19  0:25           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100310130932.GB18509@localhost \
    --to=fengguang.wu@intel.com \
    --cc=bart.vanassche@gmail.com \
    --cc=ehrhardt@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hifumi.hisashi@oss.ntt.co.jp \
    --cc=intercommit@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=randy.dunlap@oracle.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=vst@vlnb.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).