LWN: Comments on "A CLOCK-Pro page replacement implementation"

A CLOCK-Pro page replacement implementation

riel — Wed, 31 Aug 2005 19:03:42 +0000

Kernels get unstable when the maintainer only merges experimental code and drops bugfixes on the floor. Luckily these days the kernel has a decent process for making sure that doesn't happen, with patches filtering through Andrew Morton's -mm tree first, and Linus having tools to be able to merge the patches he needs to merge.

During the early 2.4 days, all of the bugfixes needed to get the VM stable were in the -ac kernels, but due to a lack of tools and process they never made it into Linus' tree...

A CLOCK-Pro page replacement implementation

nickb — Tue, 30 Aug 2005 23:20:54 +0000

It's good to see Rik back on the memory management task again. His work in the 2.3 kernels was certainly responsible for many of the stability issues of early 2.4 releases. Finally the bullet was bitten and his code removed.

I hope we don't see a repeat of this in the 2.6 kernels.

A CLOCK-Pro page replacement implementation

forthy — Thu, 25 Aug 2005 11:58:59 +0000

I've proposed something like this probably 5 years ago. Well, I've only
started a discussion, and didn't write code, and the discussion was turned
down, because the Linux kernel maintainer back then thought the VM was
"good enough" (I don't think so).

The main point in the scheme I proposed is a multi-level list of pages,
not just a two-level as it is now. Pages which have been accessed recently
elevate by one level, pages which didn't go down one level. That way,
frequently used pages end up on the top, while unused pages quickly turn
down to the bottom, making them subject for eviction. Page scanning should
depend on page age, i.e. recently allocated pages should be scanned more
often than old pages.

New pages, however, don't start at the top, but (maybe depending on how
they were allocated) somewhere in between.

My other pet peeve is the page size. My rule of thumb for random data
access is that access time and transfer time should be about the same.
I.e. 4k pages, which take 10ms to access and 0.1ms to transfer, are ways
too small. The swap in bandwidth is about 400k/s. You can write a small
memory hog which evicts most of the other programs in a second (writing
out sequential pages is easy), and then wait for a minute to have them
demand-page in again (no easy read-in of sequential pages).

At the time where the page size decission was made (~1985), the 4k size
did make sense, taking my rule of thumb into account (same 10ms access
time, but clearly less than 1MB/s transfer). Fortunately, it's only a few
years when the next larger native page size on x86 (2MB) will fit in well
with the rule of thumb, and then should be used.

A CLOCK-Pro page replacement implementation

lacostej — Thu, 18 Aug 2005 07:42:57 +0000

Once again a great article. Thanks.