linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Larry Bassel <larry.bassel@oracle.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: RFC: revisiting shared page tables
Date: Tue, 4 Dec 2018 15:16:24 -0800	[thread overview]
Message-ID: <20181204231623.GA19227@ubuette> (raw)

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

             reply	other threads:[~2018-12-04 23:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 23:16 Larry Bassel [this message]
2018-12-05  0:42 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181204231623.GA19227@ubuette \
    --to=larry.bassel@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox