lkml.org 
[lkml]   [1999]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Clearing the I/O caches? (for benchmark tests)
    From
    Date


    Larry -- Thanks for the reply and code.

    Larry McVoy <lm@bitmover.com> writes:
    > This is part of lmbench and seems to work somewhat.
    > [SNIP]

    Unfortunately this ioctl wasn't able to clear the buffer cache to the
    same level as after a reboot. The table below shows my results, I'm
    using the patch from the Linux Scalability Project
    (http://www.citi.umich.edu/projects/linux-scalability/) to instrument
    the hashes to get my lookup and hit ratios. Each row is a run of the
    build test. Before each run I call prune_dcahe(0), then a routine that
    goes through the dcache clearing all the pages of every inode, the I
    call free_inode_memory(20), and then the flushdisk code from lmbench.
    It still doesn't seem to clear the caches as well as a simple program
    that exhausts all memory, but this causes many things to die.

    Using flushdisk
    Wall Page cache Buff cache Dentry ch # num
    # clk lkups ht% lkups ht% lkups ht% # ios blks pgs csw forks
    1 44.1 55258( 68) 81439( 74) 52683( 97) # 580 1160 5913 1726 183
    ^^
    2 43.2 54587( 68) 74543( 80) 52683( 97) # 454 908 3531 1534 183
    3 42.1 54539( 68) 74323( 80) 52683( 97) # 419 838 3383 1475 183
    4 42.7 54539( 68) 74296( 80) 52683( 97) # 426 852 3391 1472 183
    5 42.8 54539( 68) 74317( 80) 52683( 97) # 427 854 3392 1476 183


    mallocing until memory's exhausted in between each run

    Wall Page cache Buff cache Dentry ch # num
    # clk lkups ht% lkups ht% lkups ht% # ios blks pgs csw forks
    1 44.0 55898( 68) 81418( 74) 52612( 97) # 529 1124 6008 1771 183
    2 45.2 55923( 68) 81118( 74) 52643( 97) # 517 1100 5974 1792 183
    3 44.5 55880( 68) 81453( 75) 52284( 98) # 429 906 5869 1563 183
    4 43.2 55881( 68) 81139( 75) 52638( 97) # 473 994 5912 1589 183
    5 44.1 55992( 68) 82094( 74) 52645( 97) # 496 1076 6078 1680 183

    I'd be content to use the memory hogging, but this has the unwanted
    side effect of causing several things (klogd and syslogd and
    occasionally init) to die.

    Is there some other place that data is stored (that still need to
    clear) that would account for the decrease in the number of buffer
    cache lookups? Am I measuring something incorrectly? Is there some
    other side effect?

    Any other suggestions, would be quite appreciated.

    Again thanks for your time and help,

    --

    tmk

    -----------------------------------------------------------------------
    Tom M. Kroeger Pray for wind
    Graduate Student, UC Santa Cruz \ Pray for waves
    e-mail: tmk@cs.ucsc.edu |\ and Pray it's your day off!
    http://www.cse.ucsc.edu/~tmk |~\
    (831) 459-4458 |__\
    (831) 426-9055 home ,----+--

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.036 / U:0.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site