lkml.org 
[lkml]   [2003]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sparse file performance (was Re: Is there a "make hole" (truncate in middle) syscall?)


    On Fri, 5 Dec 2003, Andy Isaacson wrote:
    >
    > I got curious enough to run some tests, and was suprised at the results.
    > My machine (Athlon XP 2400+, 2030 MHz, 512 MB, KT400, 2.4.22) can read
    > out of buffer cache at 234 MB/s, and off of its IDE disk at 40 MB/s.
    > I'd assumed that read(2)ing a holey file would go faster than reading
    > out of buffer cache; in theory you could do it completely in L1 cache
    > (with a 4KB buffer, it's just a ton of syscalls, some page table
    > manipulation, and a bunch of memcpy() out of a single zero page). But
    > it turns out that reading a hole is *slower* than reading data from
    > buffer cache, just 195 MB/s.

    That's because we actually instantiate the page cache pages even for
    holes. We have to, or we'd have to special-case them no end (and quite
    frankly, "hole read performance" is not something worth special casing,
    since it just isn't done under any real load).

    So reading a hole implies creating the page cache entry and _clearing_ it.
    For each page. So while you may read from the L1, you also have to do
    writeback of the _previous_ pages from the L1 into the L2 and eventually
    out to memory.

    (And eventually the VM also has to get rid of the pages etc, of course).

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

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:0.020 / U:1.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site