[lkml]   [2000]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: killing read_ahead[]

    On Thu, 26 Oct 2000, Linus Torvalds wrote:

    > The alternative is to have an entirely different approach, where the page
    > cache itself only knows about the maximum page (in which case your current
    > "last_page" calculation is right on), and then anybody who needs to know
    > about partial pages needs to get THAT information from the inode.
    > I'd almost prefer the alternative approach. Especially as right now the
    > only real problem we're fighting is to make sure we never return an
    > invalid page - the sub-page offset really doesn't matter for those things,
    > and everybody who cares about the sub-page-information already obviously
    > has it.

    s/everybody/almost &/
    There are only two places where we really care. And one of them can be
    trivially shot.
    * O_APPEND handling. Well, duh - we can take the main loop
    of generic_file_write() into a separate function (do_generic_file_write())
    and be done with that - grab the semaphore, possibly adjust the ->f_pos,
    pass the actor to do_generic_file_write(), be happy.
    * do_generic_file_read() should know how much to copy from the
    last page. We could push that into the actor. Or we could mirror that
    data in struct address_space.

    But yes, 99% of cases care only about the index of last page. So
    I really don't think that size>>PAGE_CACHE_SHIFT makes sense from VM point
    of view.

    OK, I have the "push to actor" variant and I'll send it once it
    will get some testing. Changing it to "mirror both" is not a problem, anyway.

    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:45    [W:0.020 / U:2.156 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site