[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, 30 May 2006 05:36:31 +0200, Voluspa said:
    > 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.

    Actually, it doesn't seem too aggressive at all - I have 768M of memory,
    and the larger max readahead means that it hits the disk 1/8th as often
    for a bigger slurp. Since I'm on a laptop with a slow 5400rpm 60g disk,
    a 128K seek-and-read "costs" almost exactly the same as a 1M seek-and-read...

    (If I was more memory constrained, I'd probably be hitting that --setra though ;)

    The only hard numbers I have so far are a build of a 17-rc4-mm3 kernel tree
    under -mm3+readahead and a slightly older -mm2 - the readahead kernel got
    through the build about 30 seconds faster (19 mins 45 secs versus 20:17 -but
    that's only 1 trial each).

    Oh.. another "hard number" - elapsed time for a 4AM 'tripwire' run from cron
    with a -mm3+readahead kernel was 36 minutes. A few days earlier, a -mm3
    kernel took 46 minutes for the same thing. I'll have to go and retry this
    with equivalent cache-cold scenarios - I *think* the file cache was roughly
    equivalent, but can't prove it...

    The desktop "feel" is certainly at least as good, but it's a lot harder
    to quantify that - yesterday I was doing some heavy-duty cleaning in my
    ~/Mail directory (MH-style one message per file, about 250K files and 3G,
    obviously seriously in need of cleaning). I'd often have 2 different
    'find | xargs grep' type commands running at a time, and that seemed to
    work a lot better than it used to (but again, no numbers)..

    Damn, this is a lot harder to benchmark than the sort of microbenchmarks
    we usually see around here. :)

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

    For my usage patterns, this is a feature, not a bug. As mentioned before,
    on this machine anything that reduces the number of seeks is a Good Thing.

    > Distracting in silent sequences, and perhaps increased disk wear/tear.

    It would be increased wear/tear only if the disk was idle long enough to
    spin down. Especially for video, the read-ahead needed to let the disk spin
    down (assuming a sane timeout for that) would be enormous. :)

    > I'll try adjusting the readahead size towards silence tomorrow.

    The onboard sound chip is an ok-quality CS4205, the onboard speakers are crap.
    However, running the audio through a nice pair of Kenwood headphones is a good
    solution. I don't hear the disk (or sometimes even the phone), and my
    co-workers don't have to hear my Malmsteen collection. :)

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2006-05-30 18:52    [W:0.024 / U:31.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site