Re: CPA patchset

Ingo Molnar
2008-01-10T12:22:48Z

* Andi Kleen <ak@suse.de> wrote:

> > What is very real though are the hard limitations of MTRRs. So i'd
> > rather first like to see a clean PAT approach (which all other
> > modern OSs have already migrated to in the past 10 years)
>
> That's mostly orthogonal. Don't know why you bring it up now?

because the PAT (Page Attribute Table support) patchset and the CPA
(change_page_attr()) patchset are are not orthogonal at all - as their
name already signals: because they change the implementation/effects of
the same interface(s). [just at different levels].

Both patchsets change how the kernel pagetable caching is handled. PAT
changes the kernel pte details and unshackles us from MTRR reliance and
thus solves real problems on real boxes:

55 files changed, 1288 insertions(+), 237 deletions(-)

CPA moves change_page_attr() from invwb flushing to cflush flushing, for
a speedup/latency-win, plus a whole bunch of intermingled fixes and
improvements to page attribute modification:

26 files changed, 882 insertions(+), 423 deletions(-)

so in terms of risk management, the "perfect patch order" is:

- minimal_set of correctness fixes to the highlevel cpa code.

- ( then any provably NOP cleanups to pave the way. )

- then change the lowlevel pte code (PAT) to reduce/eliminate the need
to have runtime MTRR use

- then structural improvements/cleanups of the highlevel cpa code

- then the cflush (optional) performance feature ontop of it.

- then gigabyte-largepages/TLBs support [new CPU feature that further
complicates page-attribute management]

All in an easy-to-revert fashion. We _will_ regress here, and this stuff
is very hard to debug.

Ingo