Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1544240

Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

From Mike Kravetz <mike.kravetz@oracle.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1
Date 2016-12-19 01:10 +0100
Message-ID <sPTGG-pT-25@gated-at.bofh.it> (permalink)
References <sP5Ad-7fU-9@gated-at.bofh.it> <sP5Ad-7fU-23@gated-at.bofh.it> <sPAaZ-1U9-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 12/17/2016 07:14 PM, David Miller wrote:
> From: Mike Kravetz <mike.kravetz@oracle.com>
> Date: Fri, 16 Dec 2016 10:35:27 -0800
> 
>> In current code, only context ID register 0 is set and used by the MMU.
>> On sun4v platforms that support MMU shared context, there is an additional
>> context ID register: specifically context register 1.  When searching
>> the TLB, the MMU will find a match if the virtual address matches and
>> the ID contained in context register 0 -OR- context register 1 matches.
>>
>> Load the shared context ID into context ID register 1.  Care must be
>> taken to load register 1 after register 0, as loading register 0
>> overwrites both register 0 and 1.  Modify code loading register 0 to
>> also load register one if applicable.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> 
> You can't make these register accesses if the feature isn't being
> used.
> 
> Considering the percentage of applications which will actually use
> this thing, incuring the overhead of even loading the shared context
> register is simply unacceptable.

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.

-- 
Mike Kravetz

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 04/14] sparc64: load shared id into context register 1 Mike Kravetz <mike.kravetz@oracle.com> - 2016-12-16 19:40 +0100
  Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Sam Ravnborg <sam@ravnborg.org> - 2016-12-17 08:50 +0100
    Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Mike Kravetz <mike.kravetz@oracle.com> - 2016-12-19 01:30 +0100
      Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Sam Ravnborg <sam@ravnborg.org> - 2016-12-21 19:20 +0100
  Re: [RFC PATCH 04/14] sparc64: load shared id into context  register 1 David Miller <davem@davemloft.net> - 2016-12-18 04:20 +0100
    Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Mike Kravetz <mike.kravetz@oracle.com> - 2016-12-19 01:10 +0100
      Re: [RFC PATCH 04/14] sparc64: load shared id into context  register 1 David Miller <davem@davemloft.net> - 2016-12-20 19:40 +0100
        Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Mike Kravetz <mike.kravetz@oracle.com> - 2016-12-20 21:30 +0100
      Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1 Sam Ravnborg <sam@ravnborg.org> - 2016-12-21 19:20 +0100

csiph-web