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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
