WF> I know that most of you do not like aging.
We love aging. We dislike the BS that called it self aging code.
It implemented something like least frequently used. Instead of
least recently used. We dislike least frequently used because it's a poor
predictor of pages to be used next, and a cpu hog.
WF> At this point the system performance breaks down dramatically even
WF> with 2.2.0pre[567] ...
If you could demonstrate this it would aid any plea for changing the VM system.
WF> What's about a simple aging of program page cluster or better of the
WF> page cache?
We do age pages. The PG_referenced bit. This scheme as far as I can
tell is more effective at predicting pages we are going to use next
than any we have used before.
WF> Increasing the age could be done if and only if the pages
WF> or page clusters swapped in and the program wasn't able to use its
WF> time slice. Decreasing the age could be placed in shrink_mmap().
People keep playing with ignoring PG_referenced in shrink_mmap for the swap cache,
because it doesn't seem terribly important. If you could demonstrate
this is a problem we can stop ignoring it.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/