[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: killing read_ahead[]
    On Tue, Oct 24, 2000 at 12:46:36PM -0700, Linus Torvalds wrote:
    > Actually, the _real_ answer is to make fs/block_dev.c use the page cache
    > instead - and generic_file_read() does read-ahead that actually improves
    > performance, unlike the silly contortions that the direct block-dev
    > read-ahead tries to do.

    If we had a paper about the page cache this would be easy.

    In the beginning page cache was just previously mmaped pages,
    that are clean and ready to be mapped again.

    Today we have them either dirty or clean, mapped or not(?), with and
    without buffers, in highmem(?) or lowmem and everybody and its
    children is using it for everything.

    We need a clear definition about (concurrent) states of page
    cached pages, valid transitions (and locks/sema4s to take for
    them), assumptions, guarantees etc.

    The only thing I see guaranteed, that every big thing to be
    cached should live there and is page aligned and page sized.

    I'm trying hard to understand a concept in the page cache and to
    get it's limits and guarantees, but still find it hard to get

    Time for specs, I would say ;-)

    I could help to explain and formulate, if someone could only cut
    the edges of how it works and what it will be.

    Thanks & Regards

    Ingo Oeser
    Feel the power of the penguin - run linux@your.pc
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:41    [W:0.021 / U:36.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site