From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Andrew Morton <akpm@osdl.org>
Cc: Valdis.Kletnieks@vt.edu, diegocg@gmail.com,
Voluspa <lista1@comhem.se>,
linux-kernel@vger.kernel.org
Subject: [PATCH] readahead: initial method - expected read size - fix fastcall
Date: Sun, 4 Jun 2006 15:34:15 +0800 [thread overview]
Message-ID: <349406446.10828@ustc.edu.cn> (raw)
Message-ID: <20060604073415.GB5405@mail.ustc.edu.cn> (raw)
Remove 'fastcall' directive for function readahead_close().
It has drawn concerns from Andrew Morton. Now I have some benchmarks
on it, and proved it as a _false_ optimization.
The tests are simple runs of the following command over _cached_ dirs:
time find / > /dev/null
Table of summary(averages):
user sys cpu total
fastcall: 1.236 4.39 89% 6.2936
non-fastcall: 1.18 4.14166667 92% 5.75416667
stock: 1.25833333 4.14666667 93.3% 5.75866667
-----------
Detailed outputs:
readahead patched kernel with fastcall:
noglob find / > /dev/null 1.21s user 4.58s system 90% cpu 6.378 total
noglob find / > /dev/null 1.25s user 4.47s system 86% cpu 6.623 total
noglob find / > /dev/null 1.23s user 4.36s system 90% cpu 6.173 total
noglob find / > /dev/null 1.25s user 4.33s system 92% cpu 6.067 total
noglob find / > /dev/null 1.24s user 4.21s system 87% cpu 6.227 total
readahead patched kernel without fastcall:
noglob find / > /dev/null 1.21s user 4.46s system 95% cpu 5.962 total
noglob find / > /dev/null 1.26s user 4.58s system 94% cpu 6.142 total
noglob find / > /dev/null 1.10s user 3.80s system 86% cpu 5.661 total
noglob find / > /dev/null 1.13s user 3.98s system 95% cpu 5.355 total
noglob find / > /dev/null 1.18s user 4.00s system 89% cpu 5.805 total
noglob find / > /dev/null 1.22s user 4.03s system 93% cpu 5.600 total
stock kernel:
noglob find / > /dev/null 1.22s user 4.24s system 94% cpu 5.803 total
noglob find / > /dev/null 1.31s user 4.21s system 95% cpu 5.784 total
noglob find / > /dev/null 1.27s user 4.24s system 97% cpu 5.676 total
noglob find / > /dev/null 1.34s user 4.21s system 94% cpu 5.844 total
noglob find / > /dev/null 1.26s user 4.08s system 89% cpu 5.935 total
noglob find / > /dev/null 1.15s user 3.90s system 91% cpu 5.510 total
-----------
Similar regression has also been found by Voluspa <lista1@comhem.se>:
> "cd /usr ; time find . -type f -exec md5sum {} \;"
>
> 2.6.17-rc5 ------- 2.6.17-rc5-ar
>
> real 21m21.009s -- 21m37.663s
> user 3m20.784s -- 3m20.701s
> sys 6m34.261s -- 6m41.735s
Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn>
---
--- linux-2.6.17-rc5-mm2.orig/include/linux/mm.h
+++ linux-2.6.17-rc5-mm2/include/linux/mm.h
@@ -1068,7 +1068,7 @@ unsigned long page_cache_readahead(struc
void handle_ra_miss(struct address_space *mapping,
struct file_ra_state *ra, pgoff_t offset);
unsigned long max_sane_readahead(unsigned long nr);
-void fastcall readahead_close(struct file *file);
+void readahead_close(struct file *file);
unsigned long
page_cache_readahead_adaptive(struct address_space *mapping,
struct file_ra_state *ra, struct file *filp,
--- linux-2.6.17-rc5-mm2.orig/mm/readahead.c
+++ linux-2.6.17-rc5-mm2/mm/readahead.c
@@ -1943,7 +1943,7 @@ void fastcall readahead_cache_hit(struct
* The resulted `ra_expect_bytes' answers the question of:
* How many pages are expected to be read on start-of-file?
*/
-void fastcall readahead_close(struct file *file)
+void readahead_close(struct file *file)
{
struct inode *inode = file->f_dentry->d_inode;
struct address_space *mapping = inode->i_mapping;
next reply other threads:[~2006-06-04 7:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-04 7:34 Fengguang Wu [this message]
2006-06-04 7:34 ` [PATCH] readahead: initial method - expected read size - fix fastcall Fengguang Wu
2006-06-04 9:07 ` Andrew Morton
2006-06-04 9:25 ` Arjan van de Ven
2006-06-05 1:17 ` Voluspa
2006-06-05 8:00 ` Arjan van de Ven
2006-06-06 2:26 ` Fengguang Wu
2006-06-06 2:26 ` Fengguang Wu
2006-06-08 7:31 ` Voluspa
2006-06-08 7:57 ` Fengguang Wu
2006-06-08 7:57 ` Fengguang Wu
2006-06-06 2:57 ` Fengguang Wu
2006-06-06 2:57 ` Fengguang Wu
2006-06-08 7:43 ` Voluspa
2006-06-08 8:13 ` Fengguang Wu
2006-06-08 8:13 ` Fengguang Wu
2006-06-08 8:28 ` Voluspa
2006-06-08 8:50 ` Fengguang Wu
2006-06-08 8:50 ` Fengguang Wu
2006-06-08 10:04 ` Voluspa
2006-06-04 12:13 ` [PATCH] readahead: call scheme - fix fastcall readahead_cache_hit() Fengguang Wu
2006-06-04 12:13 ` Fengguang Wu
-- strict thread matches above, loose matches on Subject: below --
2006-05-30 3:36 Adaptive Readahead V14 - statistics question Voluspa
2006-05-30 6:40 ` Wu Fengguang
2006-05-30 6:40 ` Wu Fengguang
2006-05-30 16:49 ` Valdis.Kletnieks
2006-05-31 21:06 ` Diego Calleja
2006-05-31 21:50 ` Voluspa
2006-06-01 5:51 ` Fengguang Wu
2006-06-01 5:51 ` Fengguang Wu
2006-06-01 6:35 ` Voluspa
2006-06-08 8:04 ` Voluspa
2006-06-08 11:37 ` adaptive readahead overheads Fengguang Wu
2006-06-08 11:37 ` Fengguang Wu
2006-06-08 12:25 ` Voluspa
2006-06-08 12:39 ` Fengguang Wu
2006-06-08 12:39 ` Fengguang Wu
2006-06-08 13:05 ` Andi Kleen
2006-06-08 14:00 ` Jens Axboe
[not found] ` <448493E9.9030203@samwel.tk>
2006-06-06 3:34 ` Adaptive Readahead V14 - statistics question Wu Fengguang
2006-06-06 3:34 ` Wu Fengguang
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=349406446.10828@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@osdl.org \
--cc=diegocg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lista1@comhem.se \
/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.