public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Adaptive Readahead V14 - statistics question...
@ 2006-05-30  3:36 Voluspa
       [not found] ` <20060530064026.GA4950@mail.ustc.edu.cn>
                   ` (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
[parent not found: <20060604073415.GB5405@mail.ustc.edu.cn>]

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
     [not found] ` <20060530064026.GA4950@mail.ustc.edu.cn>
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
     [not found]     ` <20060601055143.GA5216@mail.ustc.edu.cn>
2006-06-01  5:51       ` Fengguang Wu
2006-06-01  6:35         ` Voluspa
2006-06-08  8:04         ` Voluspa
     [not found]           ` <20060608113731.GA5813@mail.ustc.edu.cn>
2006-06-08 11:37             ` adaptive readahead overheads Fengguang Wu
2006-06-08 12:25               ` Voluspa
     [not found]                 ` <20060608123900.GA6885@mail.ustc.edu.cn>
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>
     [not found]   ` <20060606033436.GB6071@mail.ustc.edu.cn>
2006-06-06  3:34     ` Adaptive Readahead V14 - statistics question Wu Fengguang
     [not found] <20060604073415.GB5405@mail.ustc.edu.cn>
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
     [not found]         ` <20060606022606.GA6071@mail.ustc.edu.cn>
2006-06-06  2:26           ` Fengguang Wu
2006-06-08  7:31             ` Voluspa
     [not found]               ` <20060608075722.GA5515@mail.ustc.edu.cn>
2006-06-08  7:57                 ` Fengguang Wu
     [not found]         ` <20060606025728.GA6365@mail.ustc.edu.cn>
2006-06-06  2:57           ` Fengguang Wu
2006-06-08  7:43             ` Voluspa
     [not found]               ` <20060608081352.GB5515@mail.ustc.edu.cn>
2006-06-08  8:13                 ` Fengguang Wu
2006-06-08  8:28                   ` Voluspa
     [not found]                     ` <20060608085055.GA5917@mail.ustc.edu.cn>
2006-06-08  8:50                       ` Fengguang Wu
2006-06-08 10:04                         ` Voluspa
     [not found]     ` <20060604121328.GA6686@mail.ustc.edu.cn>
2006-06-04 12:13       ` [PATCH] readahead: call scheme - fix fastcall readahead_cache_hit() Fengguang Wu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox