The status of object-based reverse mapping

• Andrea Arcangeli's anon-vma, which adds a data structure creating a connection between each physical page and the virtual memory area (VMA) structures which reference it.

• Hugh Dickins's anonmm, which associates pages with the top-level memory management ("mm") structure instead.

The two approaches are conceptually similar, but each has its strong and weak points. Their performance is essentially equivalent. Thus far, there has not been any sort of spirited debate over which should be included; most kernel developers, if they have a preference, have kept it to themselves.

Hugh has been busy over the last few weeks, however, creating a series of 40 patches aimed at slowly moving the reverse mapping code over to the object-based approach. The first five of those patches, which are restricted to cleanup and preparatory work, have been merged into the 2.6 mainline. "rmap-10" added anonmm; it was promptly merged into the -mm tree. This action did not imply that anonmm had been chosen over anon-vma, however; it was simply the first step in the testing process which would lead to a final decision.

Hugh's final series of patches (rmap-34 to rmap-40) completes the process by replacing anonmm with anon-vma; these patches are present in 2.6.6-mm4. Hugh introduces the patch set by saying:

As Hugh notes, anon-vma should have better swapping performance, since its structures make it easier to find the VMA for a given page. Additionally, the anonmm code works best when shared anonymous pages have the same virtual address in each address space that uses them; if a process moves pages with mremap(), some relatively complicated work must be performed to make things work. The anon-vma solution does not have that particular problem.

On the other hand, expanding the VMA structure is not something which should be done lightly; some loads can use huge numbers of VMAs, and they must all be located in low memory. That said, either reverse mapping scheme should free far more low memory than it consumes; that is, after all, one of the main points behind this entire exercise.

There still has been no public word on which scheme will be chosen, or when it might be merged. The current state of affairs suggests, however, that anon-vma will be the one that goes in unless some sort of major problem turns up. As for timing: enough major work has already gone into 2.6.7 that it's hard to imagine throwing major VM surgery into the mix. So 2.6.8 is the earliest such a merge could possibly happen. A couple of 2.6 releases after that, the forking of the 2.7 tree might just become a possibility.