In August 2005, Dave McCracken sent out a patch which implemented shared
page tables (http://lkml.iu.edu/hypermail/linux/kernel/0508.3/1623.html)
based on 2.6.13.
He also wrote two OLS papers about the topic
(https://landley.net/kdocs/ols/2003/ols2003-pages-315-320.pdf
and https://www.landley.net/kdocs/ols/2006/ols2006v2-pages-125-130.pdf), the
second of which was published after his patch submission.
This patch was discussed for a few days. It was not accepted.
There were several comments about technical issues (about a typo,
some questions about locking, how to search the vmas, whether one must
iterate through all of the vmas) which no doubt could be fixed, and
in fact Dave indicated that he would eventually provide a revised patch
which fixed these problems. AFAICT this never occurred.
However, there were also questions about whether sharing page tables would
provide any significant benefit.
Specifically, there were concerns about whether the patch would
improve performance at all (Dave indicated a 3% improvement on some
"large benchmarks"), especially once another change (the test at
at the beginning of copy_page_range() which prevents page table copies
in some cases) was merged (d992895ba2, which has been in the kernel since
2.6.14).
It was also suggested that the use of randomize_vm_space
might also make shared page tables uninteresting, though that objection
appeared to be addressed.
Isn't Linux kernel archaeology fun :-)
13 years have elapsed. Given the many changes in the kernel since the original
patch submission, I'd appreciate your insight into the following questions:
* Is there (still?) a need for shared page tables (and if not, why not?).
* If one were to resume work on this, is there any reason why one shouldn't
start with Dave's 2.6.13 patch (plus fixes to the known bugs in it)
and forward port it to the tip, rather than starting from scratch?
Thanks.
Larry Bassel
Larry Bassel <[email protected]> writes:
>
> Isn't Linux kernel archaeology fun :-)
>
> 13 years have elapsed. Given the many changes in the kernel since the original
> patch submission, I'd appreciate your insight into the following questions:
I believe the main objection (from Linus) back then that it would
complicate page table locking significantly, and also add overhead for
it. If anything locking (or even lack of locking, as in lockless code)
has gotten far more hairy in the 13 years, so this issue likely got
far worse.
So if you would work on it I would start with some investigation
what the locking scheme would take, how maintainable it would be,
and how many atomics in hot paths it would add.
-Andi