linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wu Fengguang <wfg@linux.intel.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Herbert Poetzl <herbert@13thfloor.at>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] fix readahead pipeline break caused by block plug
Date: Tue, 31 Jan 2012 18:20:39 +0800	[thread overview]
Message-ID: <20120131102039.GA27668@localhost> (raw)
In-Reply-To: <1327996780.21268.42.camel@sli10-conroe>

On Tue, Jan 31, 2012 at 03:59:40PM +0800, Li, Shaohua wrote:
> Herbert Poetzl reported a performance regression since 2.6.39.

It helps to point out the exact commit that caused the regression.

 commit 55602dd66f535 ("fs: make generic file read/write functions plug")

> The test
> is a simple dd read, but with big block size. The reason is:
> 
> T1: ra (A, A+128k), (A+128k, A+256k)
> T2: lock_page for page A, submit the 256k
> T3: hit page A+128K, ra (A+256k, A+384). the range isn't submitted
> because of plug and there isn't any lock_page till we hit page A+256k
> because all pages from A to A+256k is in memory
> T4: hit page A+256k, ra (A+384, A+ 512). Because of plug, the range isn't
> submitted again.
> T5: lock_page A+256k, so (A+256k, A+512k) will be submitted. The task is
> waitting for (A+256k, A+512k) finish.
> 
> There is no request to disk in T3 and T4, so readahead pipeline breaks.

s/in/between/

> We really don't need block plug for generic_file_aio_read() for buffered
> I/O. The readahead already has plug and has fine grained control when I/O
> should be submitted. Deleting plug for buffered I/O fixes the regression.

Eric and Herbert have good performance numbers and blktrace data, it
would be good to include some of them for demonstrating this patch's
impact on both behavior and throughput :)

Thanks,
Fengguang

> One side effect is plug makes the request size 256k, the size is 128k
> without it. This is because default ra size is 128k and not a reason we
> need plug here.
> 
> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> Tested-by: Herbert Poetzl <herbert@13thfloor.at>
> Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 97f49ed..b662757 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1400,15 +1400,12 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
>  	unsigned long seg = 0;
>  	size_t count;
>  	loff_t *ppos = &iocb->ki_pos;
> -	struct blk_plug plug;
>  
>  	count = 0;
>  	retval = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE);
>  	if (retval)
>  		return retval;
>  
> -	blk_start_plug(&plug);
> -
>  	/* coalesce the iovecs and go direct-to-BIO for O_DIRECT */
>  	if (filp->f_flags & O_DIRECT) {
>  		loff_t size;
> @@ -1424,8 +1421,12 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
>  			retval = filemap_write_and_wait_range(mapping, pos,
>  					pos + iov_length(iov, nr_segs) - 1);
>  			if (!retval) {
> +				struct blk_plug plug;
> +
> +				blk_start_plug(&plug);
>  				retval = mapping->a_ops->direct_IO(READ, iocb,
>  							iov, pos, nr_segs);
> +				blk_finish_plug(&plug);
>  			}
>  			if (retval > 0) {
>  				*ppos = pos + retval;
> @@ -1481,7 +1482,6 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
>  			break;
>  	}
>  out:
> -	blk_finish_plug(&plug);
>  	return retval;
>  }
>  EXPORT_SYMBOL(generic_file_aio_read);
> 

  parent reply	other threads:[~2012-01-31 10:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31  7:59 [PATCH] fix readahead pipeline break caused by block plug Shaohua Li
2012-01-31  8:36 ` Christoph Hellwig
2012-01-31  8:48 ` Eric Dumazet
2012-01-31  8:50   ` Herbert Poetzl
2012-01-31  8:53   ` Shaohua Li
2012-01-31  9:17     ` Eric Dumazet
2012-01-31 10:20 ` Wu Fengguang [this message]
2012-01-31 10:34 ` Wu Fengguang
2012-01-31 10:46   ` Christoph Hellwig
2012-01-31 10:57     ` Wu Fengguang
2012-01-31 11:34       ` Christoph Hellwig
2012-01-31 11:42         ` Wu Fengguang
2012-01-31 11:57           ` Christoph Hellwig
2012-01-31 12:20             ` Wu Fengguang
2012-02-01  2:25   ` Shaohua Li
2012-01-31 14:47 ` Vivek Goyal
2012-01-31 20:23   ` Vivek Goyal
2012-01-31 22:03 ` Vivek Goyal
2012-01-31 22:13   ` Andrew Morton
2012-01-31 22:22     ` Vivek Goyal
2012-02-01  3:36       ` Vivek Goyal
2012-02-01  7:10         ` Wu Fengguang
2012-02-01 16:01           ` Vivek Goyal
2012-02-01  9:18         ` Christoph Hellwig
2012-02-01 20:10           ` Vivek Goyal
2012-02-01 20:13             ` Jeff Moyer
2012-02-01 20:22             ` Andrew Morton
2012-02-01  7:02   ` Wu Fengguang

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=20120131102039.GA27668@localhost \
    --to=wfg@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shaohua.li@intel.com \
    --cc=vgoyal@redhat.com \
    /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).