On 12/20/2016 10:33 AM, David Miller wrote:
> From: Mike Kravetz <mike.krav...@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
