linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
	Nick Piggin <npiggin@suse.de>, Andi Kleen <andi@firstfloor.org>,
	Steven Whitehouse <swhiteho@redhat.com>,
	David Howells <dhowells@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jonathan Corbet <corbet@lwn.net>,
	Christoph Hellwig <hch@infradead.org>,
	Wu Fengguang <fengguang.wu@intel.com>
Cc: <stable@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	<linux-fsdevel@vger.kernel.org>
Subject: [PATCH 4/4] readahead: introduce FMODE_RANDOM for POSIX_FADV_RANDOM
Date: Fri, 22 Jan 2010 12:59:18 +0800	[thread overview]
Message-ID: <20100122051517.700439492@intel.com> (raw)
In-Reply-To: 20100122045914.993668874@intel.com

[-- Attachment #1: fadvise-random.patch --]
[-- Type: text/plain, Size: 3781 bytes --]

This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM.

POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor
performance: a 16K read will be carried out in 4 _sync_ 1-page reads.

In other places, ra_pages==0 means
- it's ramfs/tmpfs/hugetlbfs/sysfs/configfs
- some IO error happened
where multi-page read IO won't help or should be avoided.

POSIX_FADV_RANDOM actually want a different semantics: to disable the
*heuristic* readahead algorithm, and to use a dumb one which faithfully
submit read IO for whatever application requests.

So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM.

Note that the random hint is not likely to help random reads performance
noticeably. And it may be too permissive on huge request size (its IO
size is not limited by read_ahead_kb).

In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall
(NFS read) performance of the application increased by 313%!

v6: use FMODE_RANDOM (proposed by Christoph Hellwig)
v5: use bit 0200000000; explicitly nuke the O_RANDOM bit in __dentry_open()
    (Stephen Rothwell)
v4: resolve bit conflicts with sparc and parisc;
    use bit 040000000(=FMODE_NONOTIFY), which will be masked out by
    __dentry_open(), so that open(O_RANDOM) is disabled
    (Stephen Rothwell and Christoph Hellwig)
v3: use O_RANDOM to indicate both read/write access pattern as in
    posix_fadvise(), although it only takes effect for read() now
    (proposed by Quentin)
v2: use O_RANDOM_READ to avoid race conditions (pointed out by Andi)

CC: Nick Piggin <npiggin@suse.de>
CC: Andi Kleen <andi@firstfloor.org>
CC: Steven Whitehouse <swhiteho@redhat.com>
CC: David Howells <dhowells@redhat.com>
CC: Al Viro <viro@zeniv.linux.org.uk>
CC: Jonathan Corbet <corbet@lwn.net>
CC: Christoph Hellwig <hch@infradead.org>
Tested-by: Quentin Barnes <qbarnes+nfs@yahoo-inc.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
 include/linux/fs.h |    3 +++
 mm/fadvise.c       |   10 +++++++++-
 mm/readahead.c     |    6 ++++++
 3 files changed, 18 insertions(+), 1 deletion(-)

--- linux-2.6.orig/mm/fadvise.c	2009-08-23 14:44:23.000000000 +0800
+++ linux-2.6/mm/fadvise.c	2010-01-22 12:57:07.000000000 +0800
@@ -77,12 +77,20 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, lof
 	switch (advice) {
 	case POSIX_FADV_NORMAL:
 		file->f_ra.ra_pages = bdi->ra_pages;
+		spin_lock(&file->f_lock);
+		file->f_flags &= ~FMODE_RANDOM;
+		spin_unlock(&file->f_lock);
 		break;
 	case POSIX_FADV_RANDOM:
-		file->f_ra.ra_pages = 0;
+		spin_lock(&file->f_lock);
+		file->f_flags |= FMODE_RANDOM;
+		spin_unlock(&file->f_lock);
 		break;
 	case POSIX_FADV_SEQUENTIAL:
 		file->f_ra.ra_pages = bdi->ra_pages * 2;
+		spin_lock(&file->f_lock);
+		file->f_flags &= ~FMODE_RANDOM;
+		spin_unlock(&file->f_lock);
 		break;
 	case POSIX_FADV_WILLNEED:
 		if (!mapping->a_ops->readpage) {
--- linux-2.6.orig/mm/readahead.c	2010-01-22 12:55:48.000000000 +0800
+++ linux-2.6/mm/readahead.c	2010-01-22 12:57:07.000000000 +0800
@@ -501,6 +501,12 @@ void page_cache_sync_readahead(struct ad
 	if (!ra->ra_pages)
 		return;
 
+	/* be dumb */
+	if (filp->f_mode & FMODE_RANDOM) {
+		force_page_cache_readahead(mapping, filp, offset, req_size);
+		return;
+	}
+
 	/* do read-ahead */
 	ondemand_readahead(mapping, ra, filp, false, offset, req_size);
 }
--- linux-2.6.orig/include/linux/fs.h	2010-01-22 12:55:47.000000000 +0800
+++ linux-2.6/include/linux/fs.h	2010-01-22 12:57:08.000000000 +0800
@@ -87,6 +87,9 @@ struct inodes_stat_t {
  */
 #define FMODE_NOCMTIME		((__force fmode_t)2048)
 
+/* Expect random access pattern */
+#define FMODE_RANDOM		((__force fmode_t)0x1000)
+
 /*
  * The below are the various read and write types that we support. Some of
  * them include behavioral modifiers that send information down to the

  parent reply	other threads:[~2010-01-22  4:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-22  4:59 [PATCH 0/4] devmem and readahead fixes for 2.6.33 Wu Fengguang
2010-01-22  4:59 ` [PATCH 1/4] devmem: check vmalloc address on kmem read/write Wu Fengguang
2010-01-22  4:59 ` [PATCH 2/4] devmem: fix kmem write bug on memory holes Wu Fengguang
2010-01-22  4:59 ` [PATCH 3/4] vfs: take f_lock on modifying f_mode after open time Wu Fengguang
2010-01-22  4:59 ` Wu Fengguang [this message]
2010-01-22  5:31 ` [PATCH 0/4] devmem and readahead fixes for 2.6.33 Greg KH
2010-01-27  0:50   ` Andrew Morton
2010-01-27  1:39     ` Greg KH
2010-01-27  2:45     ` Wu Fengguang
2010-02-03 23:47 ` [stable] " Greg KH
2010-02-04  2:42   ` [stable] [PATCH] devmem: check vmalloc address on kmem read/write Wu Fengguang
2010-02-04  2:43     ` [stable] [PATCH] devmem: fix kmem write bug on memory holes Wu Fengguang
2010-02-04  2:58     ` [stable] [PATCH] devmem: check vmalloc address on kmem read/write KAMEZAWA Hiroyuki
2010-02-04  3:18       ` Wu Fengguang
2010-02-04  3:27         ` KAMEZAWA Hiroyuki

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=20100122051517.700439492@intel.com \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=npiggin@suse.de \
    --cc=swhiteho@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).