* Andi Kleen <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/