On 12/20/2016 10:33 AM, David Miller wrote: > From: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > Date: Sun, 18 Dec 2016 16:06:01 -0800 > >> Ok, let me try to find a way to eliminate these loads unless the application >> is using shared context. >> >> Part of the issue is a 'backwards compatibility' feature of the processor >> which loads/overwrites register 1 every time register 0 is loaded. Somewhere >> in the evolution of the processor, a feature was added so that register 0 >> could be loaded without overwriting register 1. That could be used to >> eliminate the extra load in some/many cases. But, that would likely lead >> to more runtime kernel patching based on processor level. And, I don't >> really want to add more of that if possible. Or, perhaps we only enable >> the shared context ID feature on processors which have the ability to work >> around the backwards compatibility feature. > > Until the first process uses shared mappings, you should not touch the > context 1 register in any way for any reason at all. > > And even once a process _does_ use shared mappings, you only need to > access the context 1 register in 2 cases: > > 1) TLB processing for the processes using shared mappings. > > 2) Context switch MMU state handling, where either the previous or > next process is using shared mappings. I agree. But, we still need to address the issue of existing code that is overwriting context register 1 today. Due to that backwards compatibility feature, code like: mov SECONDARY_CONTEXT, %g3 stxa %g2, [%g3] ASI_DMMU will store not only to register 0, but register 1 as well. In this RFC, I used an ugly brute force method of always restoring register 1 after storing register 0 to make sure any unique value in register 1 was preserved. I agree this is not acceptable and needs to be fixed. We could check if register 1 is in use and only do the save/restore in that case. But, that is still an additional check. The Sparc M7 processor has new ASIs to handle this better: ASI ASI Name R/W VA Per Strand Description 0x21 ASI_MMU RW 0x28 Y I/DMMUPrimary Context register 0 (no Primary Context register 1 update) 0x21 ASI_MMU RW 0x30 Y DMMUSecondary Context register 0 (no Secondary Context register 1 update) More details at, http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-architecture-supplement-3093429.pdf Of course, this could only be used on processors where the new ASIs are available. Still need to think about the best way to handle this. -- Mike Kravetz -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>