All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Fengguang Wu <wfg@mail.ustc.edu.cn>
Cc: 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 3/3] readahead: scale max readahead size depending on memory size
Date: Sun, 22 Jul 2007 10:59:11 +0200	[thread overview]
Message-ID: <1185094751.20032.221.camel@twins> (raw)
In-Reply-To: <385093918.09754@ustc.edu.cn>

On Sun, 2007-07-22 at 16:45 +0800, Fengguang Wu wrote:
> On Sat, Jul 21, 2007 at 11:00:08PM +0200, Peter Zijlstra wrote:
> > Scale the default max readahead size with the system memory size.
> > 
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > ---
> >  block/ll_rw_blk.c  |    2 +-
> >  include/linux/fs.h |    1 +
> >  mm/readahead.c     |   32 ++++++++++++++++++++++++++++++++
> >  3 files changed, 34 insertions(+), 1 deletion(-)
> > 
> > Index: linux-2.6/block/ll_rw_blk.c
> > ===================================================================
> > --- linux-2.6.orig/block/ll_rw_blk.c
> > +++ linux-2.6/block/ll_rw_blk.c
> > @@ -208,7 +208,7 @@ void blk_queue_make_request(request_queu
> >  	blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
> >  	blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
> >  	q->make_request_fn = mfn;
> > -	q->backing_dev_info.ra_pages = (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
> > +	bdi_ra_init(&q->backing_dev_info);
> 
> fs/fuse/inode.c has another line to be converted.

Drad, right you are. Will grep a bit.

> >  	q->backing_dev_info.state = 0;
> >  	q->backing_dev_info.capabilities = BDI_CAP_MAP_COPY;
> >  	blk_queue_max_sectors(q, SAFE_MAX_SECTORS);
> > Index: linux-2.6/include/linux/fs.h
> > ===================================================================
> > --- linux-2.6.orig/include/linux/fs.h
> > +++ linux-2.6/include/linux/fs.h
> > @@ -1696,6 +1696,7 @@ extern long do_splice_direct(struct file
> >  
> >  extern void
> >  file_ra_state_init(struct file_ra_state *ra, struct address_space *mapping);
> > +extern void bdi_ra_init(struct backing_dev_info *bdi);
> >  extern loff_t no_llseek(struct file *file, loff_t offset, int origin);
> >  extern loff_t generic_file_llseek(struct file *file, loff_t offset, int origin);
> >  extern loff_t remote_llseek(struct file *file, loff_t offset, int origin);
> > Index: linux-2.6/mm/readahead.c
> > ===================================================================
> > --- linux-2.6.orig/mm/readahead.c
> > +++ linux-2.6/mm/readahead.c
> > @@ -42,6 +42,38 @@ file_ra_state_init(struct file_ra_state 
> >  }
> >  EXPORT_SYMBOL_GPL(file_ra_state_init);
> >  
> > +static unsigned long ra_pages;
> > +
> > +static __init int readahead_init(void)
> > +{
> > +	/*
> > +	 * Scale the max readahead window with system memory
> > +	 *
> > +	 *   64M:   128K
> > +	 *  128M:   180K
> > +	 *  256M:   256K
> > +	 *  512M:   360K
> > +	 *    1G:   512K
> > +	 *    2G:   724K
> > +	 *    4G:  1024K
> > +	 *    8G:  1448K
> > +	 *   16G:  2048K
> > +	 */
> > +	ra_pages = int_sqrt(totalram_pages/16);
> > +	if (ra_pages > (2 << (20 - PAGE_SHIFT)))
> > +		ra_pages = 2 << (20 - PAGE_SHIFT);
> 
> We can elaborate on the numbers ;)
> 
> How about the following rules?
> - limit it under 1MB: we have to consider latencies

readahead is done async and we have these cond_resched() things
sprinkled all over, no?

> - make them alignment-friendly, i.e. 128K, 256K, 512K, 1M.

Would that actually matter? but yeah, that seems like a sane suggestion.
roundup_pow_of_two() comes to mind.

> My original plan is to simply do the following:
> 
> - #define VM_MAX_READAHEAD        128     /* kbytes */
> + #define VM_MAX_READAHEAD        512     /* kbytes */

Yeah, the trouble I have with that is that it might adversely affect
tiny systems (although the trash detection might mitigate that impact)

> I'd like to post some numbers to back-up the discussion:
> 
>   readahead   readahead
>        size        miss
>        128K         38%
>        512K         45%
>       1024K         49%
> 
> The numbers are measured on a fresh booted KDE desktop.
> 
> The majority misses come from the larger mmap read-arounds.

the mmap code never gets into readahead unless madvise(MADV_SEQUENTIAL)
is used afaik.

> Sequential readahead hits are pretty high and not quite affected by
> the readahead size, thanks to its size ramp-up process.
> 
> > +
> > +	return 0;
> > +}
> > +
> > +subsys_initcall(readahead_init);
> 
> Remove the global ra_pages and fold readahead_init() into bdi_ra_init()?
> bdi_ra_init will only be called several times I guess.

I guess we could, this just seemed like a proper setup where more things
could grow into.


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

Thread overview: 45+ 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 [this message]
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
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

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=1185094751.20032.221.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=csnook@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lnxninja@us.ibm.com \
    --cc=riel@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=wfg@mail.ustc.edu.cn \
    /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.