Messages in this thread | | | Subject | Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 | From | Mike Kravetz <> | Date | Tue, 20 Dec 2016 12:27:28 -0800 |
| |
On 12/20/2016 10:33 AM, David Miller wrote: > From: Mike Kravetz <mike.kravetz@oracle.com> > 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
| |