[lkml]   [2006]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Adaptive Readahead V14 - statistics question...
    On Tue, May 30, 2006 at 05:36:31AM +0200, Voluspa wrote:
    > 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.

    Hmm... It seems risky to increase the default readahead size.
    I would appreciate a feed back when you are settled with some new
    size, thanks.

    btw, maybe you will be interested in the 'laptop mode'.
    It prolongs battery life by making disk activity "bursty":

    > 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_

    I have never did 'cp' tests, because it involves writes caching
    problems. Which makes the result hard to interpret. However I will
    try to explain the two tests.

    > 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

    - only size matters in this trivial case.
    - the increased size generally do not help single reading speed.
    - but it helped reducing overhead(i.e. decreased user/sys time)
    - not sure why real time increased so much.

    > 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

    - the small files optimization in the new logic helped a little

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-30 08:42    [W:0.056 / U:14.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site