• ICE talk notes

Notes regarding the October 2006 talk on our page table work, see ICE abstract notes for a starting point

The talk is in disy cvs under papers/gelato_oct06/pti+superpage. The talk needs to discuss our superpage, PTI and GPT work.

• You need texpower installed to compile the talk slides. You can then view the pres.display.ps file with something like pspresent.
• The talk is a standard 20min presentation slot, with I assume another 10min for questions. This gives about 15 pages of slides to play with.

Breakdown

Quick breakdown of the talk structure.

• We need to determin how many slides to dedicate to each section, or at least have the points for each section put down.
• What results, if any, do we want to/can show?

Introduction

After overview, start with a recap of the current state of the Linux page table and its iteration with the rest of the virtual memory subsystem. This gives a point of reference to the work presented in the rest of the talk.

Page table interface

Superpages

• i added my work directly into cvs

Guarded page tables

• See stuff in cvs.

Pauls Initial early outline will be here soon

• At the moment I am just thinking out loud to myself -- making NOTES.
• I think Superpages should be first in the talk. My reasoning for this is that since Ian's work is more "mature". We should try to avoid tainting his work with the speculative, less mature PTI/GPT work.
• What is Peter's lecture/talk style? Does he like lots of info on a slide, or just a handful of points?

  • PeterChubb: Pictures, pictures, pictures. Animated pictures are even better (I use Chuck's trick of hiding layers in the generated EPS, so that the bounding box is the same from page to page). Although we want to end up with around 15--20 slides, some of those can and should be split into several animations. See, e.g., http://www.gelato.org/pdf/oct2005/gelato_oct2005_paravirutalization_chubb_unsw.pdf for a talk that went for 20 minutes and included a live demo for 5 minutes. PaulDavies: OK.

• Assumed audience level of knowledge: very high to extreme. Very different audience to LCA.

Proposed Structure: ~15 slides
1) Introduction - introductory slide for Superpage/PTI/GPT ~1 slide
2) Superpages - ~6 pages.
3) PTI
4) MLPT 5) GPT

Introduction

• Gelato@UNSW is fundamentally looking to question two core VM design decisions. 1) Single page size (Superpages) 2) Single page table implementation (PTI/GPT)

PTI

• ISSUES TO ADDRESS

-- Condense intro, too simple for these guys.Get into heavy stuff sooner.

• What does a clean PTI mean?
  • A page table that is always accessed via an implementation independent interface. The page table must be accessed in a manner that does not assume an implementation. This creates some issues - explain them.
  • The Kernel does not do this - give examples (copy, unmap and tear down).

• Advantages of having no PTI.
  • Simple
  • Very fast for chosen implementation.
  • Flexible - thanks to simplicity. see macros in pgtable.h
• Disadvantages of having no PTI
  • Ties OS to an implementation (debatable as to whether a disadvantage)
    • The MLPT - the fixed level heirarchical page table (trie)
  • Ties OS to a primary architecture, ie. x86 (debatable as to whether a disadvantage)
    • It has anointed x86 as the primary architecture because it was first, not because it is good. Now x86 rules through ubiquity and economies of scale.
  • Conceptually ugly (academic debate)
    • An OS should be designed for speed, not readability.

• Cost of PTI
  • Accessing a page table directly will be faster than access via a PTI.
  • Some architectures need only the incumbent page table implementation. For these, the PTI is a cost only.
  • For architectures that are suited to changing page tables, the cost of the PTI can be brought back directly, or offset, by a page table implementation that offers enhancements.(improve) eg: better for superpages (add).

• Progress Achieved
  • Abstracted the 2.6.17.1 kernel page table implementation into its own layer and called the implementation from a generic interface.
  • Measured the cost of the PTI - benchmarked 2.6.12 kernel with and without PTI.
  • Started to experiment with alternate page table implementations.

• Problems Encountered
  • The page tables are accessed from many functions across many files eg: memory.c, rmap.c, etc. making it difficult to maintain. Ideally it is the kind of project that requires upstream acceptance.
  • The kernel is further entrenching itself
  • At the moment, kernel hackers remain to be convinced that alternate page tables are required in the near future.
• The Interface: Page table operations
  • Create/destroy
  • Lookup
  • Build
  • Iteration
  • Tear down

• What are the benefits of changing page table implementation?
  • Virtualisation. Discuss
  • Superpages, page table sharing etc. (maybe use as lead in to next section).

• The PTI can be used as a vehicle for changing page tables for the purposes of experimentation. (AIM)
• We have abstracted the page table into its own layer and are accessing it through a clean interface. (DONE)
• Upstream inclusion of a PTI would be ultimate goal. (AIM)
• Possible uses for the PTI.
  • Virtualisation. Explain why different PTs would assist virtualisation.
  • More "ideal" design goal.
• The attitude of the Linux community to the PTI
  • NOT GOOD. Disinterested in general.
• What architectures are suited to changing page tables?
  • Why?
• What is required to use our PTI?
  • If an architecture is not suited to changing page table - the arch continues open access to data structure.
  • All generic kernel code accessing the page table does so by calling the interface and DOES not assume an implementation of the page table.
• Cost of PTI.
  • The PTI in itself will necessarily incur a some cost. Linus et al know what they were doing. Direct access has its advantages. What are they?
  • Must buy back the cost of the PTI with the advantages of the alternate page table implementations. Unfortunately we can't buy this cost back for archs that will not be changing page tables. Changing the page table often doesn't even benefit arches that can change page table.
• Success
• Future

Conclusion