[lkml]   [2006]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/34] mm: Page Replacement Policy Framework

    On Thu, 23 Mar 2006, Marcelo Tosatti wrote:
    > Nope, LRU only beat CLOCK-Pro/CART on the "UMass trace" (which is trace
    > replay, which can be very sensitive and not necessarily meaningful).
    > Needs more study though (talk is cheap).

    Umm.. That _trace_ was the only thing that seemed to have any real-life
    dataset, afaik. The others were totally synthetic.

    > Anyway, smarter algorithms such as this two have been proven to be more
    > efficient than LRU under a large range of real life loads. LRU's lack of
    > frequency information is really terrible.
    > LRU's worst case scenarios were well known before I was born.

    The kernel doesn't actually use LRU, so the fact that LRU isn't good seems
    a non-argument.

    > - "Every time I wake up in the morning updatedb has thrown my applications
    > out of memory".
    > - "Linux is awful every time I untar something larger than memory to disk".

    People seem to think that the fact that there are bad behaviours means
    that there are somehow "magic" algorithms that don't have bad behaviours.

    I'd really suggest somebody show better real-life numbers with a new
    algorithm _before_ we do anything like this.

    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.020 / U:7.656 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site