All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Quentin Barnes <qbarnes+nfs@yahoo-inc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Nick Piggin <npiggin@suse.de>,
	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>
Subject: Re: [RFC][PATCH v3] readahead: introduce O_RANDOM for POSIX_FADV_RANDOM
Date: Tue, 5 Jan 2010 10:16:53 +0800	[thread overview]
Message-ID: <20100105021652.GA29428@localhost> (raw)
In-Reply-To: <28c262361001041746j1270e2d2i79a932efca861dc5@mail.gmail.com>

On Tue, Jan 05, 2010 at 09:46:09AM +0800, Minchan Kim wrote:
> On Mon, Jan 4, 2010 at 9:16 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > Hi Minchan,
> >
> > On Mon, Jan 04, 2010 at 01:20:49PM +0800, Minchan Kim wrote:
> >> > --- linux.orig/mm/readahead.c   2010-01-04 12:39:29.000000000 +0800
> >> > +++ linux/mm/readahead.c        2010-01-04 12:39:30.000000000 +0800
> >> > @@ -501,6 +501,12 @@ void page_cache_sync_readahead(struct ad
> >> >        if (!ra->ra_pages)
> >> >                return;
> >> >
> >> > +       /* be dumb */
> >> > +       if (filp->f_flags & O_RANDOM) {
> >> > +               force_page_cache_readahead(mapping, filp, offset, req_size);
> >> > +               return;
> >> > +       }
> >> > +
> >>
> >> Let me have a dumb question. :)
> >>
> >> How about testing O_RANDOM in front of ra_pages testing?
> >>
> >> My intention is that although we turn off ra, it would be better to read
> >> contiguous block all at once than readpage() callback doing I/O
> >> one page at a time.
> >>
> >> Is it break some semantics or happen some problem in ondemand readahead?
> >
> > Yes it will have some problem with shrink_readahead_size_eio(), which
> > want to disable readahead and use ->readpage() when ra_pages==0.
> >
> > Do you have specific use case in mind? The file systems that set
> > ra_pages=0 seems to don't need readahead, too.
> 
> Never mind. It's just out of curiosity. :)
> 
> I thought although user disable readahead, we could enhance file I/O
> with one readpages not multiple readpage if we know the user want to
> read big contiguous blocks.

Yes, not-break-large-read-into-pages would be good for HD/SSD drives
when readahead is disabled.

Currently, ->ra_pages is somehow overloaded in its ==0 case. As you
said, it's in fact possible to disable readahead while still limiting
read IO size to a non-zero ->ra_pages.

> But I though it break current readahead off semantics. right?

It can be done by applying the ->ra_pages limit to O_RANDOM. This also
makes O_RANDOM safer to use:

@@ -497,6 +497,13 @@ void page_cache_sync_readahead(struct ad
                               struct file_ra_state *ra, struct file *filp,
                               pgoff_t offset, unsigned long req_size)
 {
+       /* be dumb */
+       if (filp->f_flags & O_RANDOM) {
+               req_size = clamp_t(unsigned long, req_size, 1, ra->ra_pages);
+               force_page_cache_readahead(mapping, filp, offset, req_size);
+               return;
+       }
+      
        /* no read-ahead */
        if (!ra->ra_pages)
                return;

To make real change, we need an interface for the user to disable
whole-partition readahead by setting O_RANDOM instead of ra_pages=0.
That would be a hard sell..

> Thanks for reply about my dumb question, Wu. :)

You are welcome :)

Thanks,
Fengguang

  reply	other threads:[~2010-01-05  2:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-25  0:07 [RFC][PATCH] Disabling read-ahead makes I/O of large reads small Quentin Barnes
2009-12-29 18:04 ` Andi Kleen
2009-12-30  5:15   ` Wu Fengguang
2009-12-30  5:17     ` [RFC][PATCH 1/2] readahead: replace ra->mmap_miss with ra->flags Wu Fengguang
2009-12-30  5:24     ` [RFC][PATCH 2/2] readahead: avoid page-by-page reads on POSIX_FADV_RANDOM Wu Fengguang
2009-12-30 18:02       ` Andi Kleen
2009-12-31  1:39         ` Wu Fengguang
2009-12-31  2:53           ` Wu Fengguang
2009-12-31  3:03             ` Wu Fengguang
2009-12-31  4:31         ` [RFC][PATCH v2] readahead: introduce O_RANDOM_READ for POSIX_FADV_RANDOM Wu Fengguang
2010-01-08 13:08           ` Christoph Hellwig
2010-01-09 13:59             ` Wu Fengguang
2010-01-09 14:01               ` Wu Fengguang
2010-01-04  4:50         ` [RFC][PATCH v3] readahead: introduce O_RANDOM " Wu Fengguang
2010-01-04  5:17           ` Stephen Rothwell
2010-01-04  7:33             ` Christoph Hellwig
2010-01-04 12:56               ` [RFC][PATCH v4] " Wu Fengguang
2010-01-05  2:03                 ` Stephen Rothwell
2010-01-05  2:26                   ` Wu Fengguang
2010-01-05  2:28                     ` Stephen Rothwell
2010-01-05  2:45                       ` Wu Fengguang
2010-01-05  5:21                         ` Eric Paris
2010-01-05  3:18                       ` [RFC][PATCH v5] " Wu Fengguang
2010-01-05  3:27                         ` Wu Fengguang
2010-01-04 16:50               ` [RFC][PATCH v3] " Quentin Barnes
2010-01-04 18:57                 ` Andreas Dilger
2010-01-04  5:20           ` Minchan Kim
2010-01-04  5:20             ` Minchan Kim
2010-01-04 12:16             ` Wu Fengguang
2010-01-05  1:46               ` Minchan Kim
2010-01-05  1:46                 ` Minchan Kim
2010-01-05  2:16                 ` Wu Fengguang [this message]
2010-01-05  3:40                   ` Minchan Kim
2010-01-05  3:40                     ` Minchan Kim

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=20100105021652.GA29428@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan.kim@gmail.com \
    --cc=npiggin@suse.de \
    --cc=qbarnes+nfs@yahoo-inc.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.