[lkml]   [2003]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: statfs() / statvfs() syscall ballsup...

    On 12 Oct 2003, Greg Stark wrote:
    > There are other reasons databases want to control their own cache. The
    > application knows more about the usage and the future usage of the data than
    > the kernel does.

    But this again is not an argument for not using the page cache - it's only
    an argument for _telling_ the kernel about its use.

    > However on busy servers whenever it's run it causes lots of pain because the
    > kernel flushes all the cached data in favour of the data this job touches.

    Yes. But this is actually pretty easy to avoid in-kernel, since all of the
    LRU logic is pretty localized.

    It could be done on a per-process thing ("this process should not pollute
    the active list") or on a per-fd thing ("accesses through this particular
    open are not to pollute the active list").

    > And
    > worse, there's no way to indicate that the i/o it's doing is lower priority,
    > so i/o bound servers get hit dramatically.

    IO priorities are pretty much worthless. It doesn't _matter_ if other
    processes get preferred treatment - what is costly is the latency cost of
    seeking. What you want is not priorities, but batching.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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