From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
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 16:45:26 +0800 [thread overview]
Message-ID: <385093918.09754@ustc.edu.cn> (raw)
Message-ID: <20070722084526.GB6317@mail.ustc.edu.cn> (raw)
In-Reply-To: <20070721210052.497469000@chello.nl>
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.
> 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
- make them alignment-friendly, i.e. 128K, 256K, 512K, 1M.
My original plan is to simply do the following:
- #define VM_MAX_READAHEAD 128 /* kbytes */
+ #define VM_MAX_READAHEAD 512 /* kbytes */
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.
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.
> +
> +void bdi_ra_init(struct backing_dev_info *bdi)
> +{
> + bdi->ra_pages = ra_pages;
> +}
> +EXPORT_SYMBOL(bdi_ra_init);
next prev parent reply other threads:[~2007-07-22 8:45 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 [this message]
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
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=385093918.09754@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=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 \
/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.