All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@gmail.com>
To: Dave Jones <davej@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	riel <riel@redhat.com>, Andrew Morton <akpm@linux-foundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tim Pepper <lnxninja@us.ibm.com>, Chris Snook <csnook@redhat.com>
Subject: Re: [PATCH 0/3] readahead drop behind and size adjustment
Date: Sun, 22 Jul 2007 16:10:10 +0800	[thread overview]
Message-ID: <385091802.23116@ustc.edu.cn> (raw)
Message-ID: <20070722081010.GA6317@mail.ustc.edu.cn> (raw)
In-Reply-To: <20070722024428.GA724@redhat.com>

On Sat, Jul 21, 2007 at 10:44:28PM -0400, Dave Jones wrote:
> On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
>  
>  > It makes sense to raise it beyond 128K.  1M default readahead
>  > absolutely makes sense for sequential workloads.  For the desktop,
>  > this increases boot speed and readahead misses, both due to more
>  > aggressive mmap read-around. Most users will be glad to feel the
>  > speedup, and happily ignore the readahead misses, which may be
>  > "invisible" in case of large memory.
>  > 
>  > In theory, the distributions can do the same tuning.  So we have an
>  > interesting question for Dave:
>  >         Does fedora desktop raise the default readahead size? Why or
>  >         why not?  It goes so far to do userland readahead ;)
>  
> Fedora takes whatever defaults for readahead the kernel.org kernel has.
> The only reasoning being if anyone reported VM bugs, we'd be able
> to say to interested upstream developers "we're running the stock VM".
> without having to get the user to try and reproduce on unpatched
> kernels.

Thank you.  Now I'm more confident that the kernel should have a
reasonable default readahead size. The current one is 5+ years old and
should be updated now.

>  > - drop behind
>  > 
>  > Sorry, I still doubt it will benefit all/most workloads. Leave it off
>  > by default, and leave the enabling decision to Dave? I do hope that
>  > it help general desktops.
> 
> It's not a subject that I'm intimatly familiar with, and when it
> comes to decisions like this, I tend to just take whatever the
> upstream defaults are.

- It will avoid large-file-reads-thrashing-my-desktop problem,
  so most desktop users should like it. But sure there will be counter
  cases when a user want to keep the data cached.
- File servers may hurt from it. Imagine a mp3/png file server. The
  files are large enough to trigger drop-behind, but small (and hot)
  enough to be cached. Also when a new fedora DVD iso is released, it
  may be cached for some days. These are only the obvious cases.

So I opt for it being made tunable, safe, and turned off by default.


  reply	other threads:[~2007-07-22  8:10 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-21 21:00 [PATCH 0/3] readahead drop behind and size adjustment Peter Zijlstra
2007-07-21 21:00 ` [PATCH 1/3] readahead: drop behind Peter Zijlstra
2007-07-21 20:29   ` Eric St-Laurent
2007-07-21 20:37     ` Peter Zijlstra
2007-07-21 20:59       ` Eric St-Laurent
2007-07-21 21:06         ` Peter Zijlstra
2007-07-25  3:55   ` Eric St-Laurent
2007-07-21 21:00 ` [PATCH 2/3] readahead: fadvise drop behind controls Peter Zijlstra
2007-07-21 21:00 ` [PATCH 3/3] readahead: scale max readahead size depending on memory size Peter Zijlstra
2007-07-22  8:24   ` Jens Axboe
2007-07-22  8:36     ` Peter Zijlstra
2007-07-22  8:50       ` Jens Axboe
2007-07-22  9:17         ` Peter Zijlstra
2007-07-22 16:44           ` Jens Axboe
2007-07-23 10:04             ` Jörn Engel
2007-07-23 10:11               ` Jens Axboe
2007-07-23 22:44               ` Rusty Russell
2007-07-22 23:52         ` Rik van Riel
2007-07-23  5:22           ` Jens Axboe
2007-07-22  8:45   ` Fengguang Wu
2007-07-22  8:45     ` Fengguang Wu
2007-07-22  8:59       ` Peter Zijlstra
2007-07-22  9:53         ` Fengguang Wu
2007-07-22  9:53           ` Fengguang Wu
2007-07-22  2:39 ` [PATCH 0/3] readahead drop behind and size adjustment Fengguang Wu
2007-07-22  2:39   ` Fengguang Wu
2007-07-22  2:44   ` Dave Jones
2007-07-22  8:10     ` Fengguang Wu [this message]
2007-07-22  8:10       ` Fengguang Wu
2007-07-22  8:24         ` Peter Zijlstra
2007-07-22  8:29           ` Fengguang Wu
2007-07-22  8:29             ` Fengguang Wu
2007-07-22  8:33       ` Rusty Russell
2007-07-22  8:45         ` Peter Zijlstra
2007-07-23  9:00         ` Nick Piggin
2007-07-23 14:24           ` Fengguang Wu
2007-07-23 14:24             ` Fengguang Wu
2007-07-23 19:40               ` Andrew Morton
2007-07-24  0:47                 ` Fengguang Wu
2007-07-24  0:47                   ` Fengguang Wu
2007-07-24  1:17                     ` Andrew Morton
2007-07-24  8:50                       ` Andreas Dilger
2007-07-24  4:30                     ` Nick Piggin
2007-07-25  4:35           ` Eric St-Laurent
2007-07-25  5:19             ` Nick Piggin
2007-07-25  6:18               ` Eric St-Laurent
2007-07-25  7:09                 ` Nick Piggin
2007-07-25  7:48                   ` Eric St-Laurent
2007-07-25 15:36                     ` Rik van Riel
2007-07-25 15:33                   ` Rik van Riel
2007-07-29  7:44                   ` Eric St-Laurent
2007-07-25 15:28               ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2007-07-22 11:11 Al Boldi

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=385091802.23116@ustc.edu.cn \
    --to=fengguang.wu@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=csnook@redhat.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lnxninja@us.ibm.com \
    --cc=riel@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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.