All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Adaptive Readahead V14 - statistics question...
@ 2006-05-30  3:36 Voluspa
  2006-05-30  6:40   ` Wu Fengguang
                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: Voluspa @ 2006-05-30  3:36 UTC (permalink / raw)
  To: wfg; +Cc: Valdis.Kletnieks, linux-kernel


Sorry about the top-post, I'm not subscribed.

On 2006-05-30 0:37:57 Wu Fengguang wrote:
> On Mon, May 29, 2006 at 03:44:59PM -0400, Valdis Kletnieks wrote:
[...]
>> doing anything useful? (One thing I've noticed is that xmms, rather
>> than gobble up 100K of data off disk every 10 seconds or so, snarfs
>> a big 2M chunk every 3-4 minutes, often sucking in an entire song at
>> (nearly) one shot...)
>
> Hehe, it's resulted from the enlarged default max readahead size(128K
> => 1M). Too much aggressive? I'm interesting to know the recommended
> size for desktops, thanks. For now you can adjust it through the
> 'blockdev --setra /dev/hda' command.

And notebooks? I'm running a 64bit system with 2gig memory and a 7200
RPM disk. Without your patches a movie like Elephants_Dream_HD.avi
causes a continuous silent read. After patching 2.6.17-rc5 (more on that
later) there's a slow 'click-read-click-read-click-etc' during the
same movie as the head travels _somewhere_ to rest(?) between reads.

Distracting in silent sequences, and perhaps increased disk wear/tear.
I'll try adjusting the readahead size towards silence tomorrow.

But as size slides in a mainstream direction, whence will any benefit
come - in this Joe-average case? It's not a faster 'cp' at least:

_Cold boot between tests - Copy between different partitions_

2.6.17-rc5-proper (Elephants_Dream_HD.avi 854537054 bytes)

real    0m44.050s
user    0m0.076s
sys     0m6.344s

2.6.17-rc5-patched

real    0m49.353s
user    0m0.075s
sys     0m6.287s

2.6.17-rc5-proper (compiled kernel tree linux-2.6.17-rc5 ~339M)

real    0m47.952s
user    0m0.198s
sys     0m6.118s

2.6.17-rc5-patched

real    0m46.513s
user    0m0.200s
sys     0m5.827s

Of course, my failure to see speed-ups could well be 'cos of a botched
patch transfer (or some kind of missing groundwork only available in
-mm). There was one reject in particular which made me pause. I'm no
programmer... and 'continue;' is a weird direction. At the end I settled
on:

[mm/readahead.c]
@@ -184,8 +289,10 @@
 					page->index, GFP_KERNEL)) {
 			ret = mapping->a_ops->readpage(filp, page);
 			if (ret != AOP_TRUNCATED_PAGE) {
-				if (!pagevec_add(&lru_pvec, page))
+				if (!pagevec_add(&lru_pvec, page)) {
+					cond_resched();
 					__pagevec_lru_add(&lru_pvec);
+				}
 				continue;
 			} /* else fall through to release */
 		}

The full 82K experiment can temprarily be found at this location:
http://web.comhem.se/~u46139355/storetmp/adaptive-readahead-v14-linux-2.6.17-rc5-part-01to28of32.patch

At least it hasn't eaten my (backed up) disk yet ;-)

Mvh
Mats Johannesson
--

^ permalink raw reply	[flat|nested] 29+ messages in thread
* [PATCH] readahead: initial method - expected read size - fix fastcall
@ 2006-06-04  7:34 ` Fengguang Wu
  2006-06-04  9:07   ` Andrew Morton
  0 siblings, 1 reply; 29+ messages in thread
From: Fengguang Wu @ 2006-06-04  7:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Valdis.Kletnieks, diegocg, Voluspa, linux-kernel

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;

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2006-06-08 14:00 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
  -- strict thread matches above, loose matches on Subject: below --
2006-06-04  7:34 [PATCH] readahead: initial method - expected read size - fix fastcall Fengguang Wu
2006-06-04  7:34 ` 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

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.