mbox series

[0/2] mips: Introduce some IO-accessors optimizations

Message ID 20200920110010.16796-1-Sergey.Semin@baikalelectronics.ru (mailing list archive)
Headers show
Series mips: Introduce some IO-accessors optimizations | expand

Message

Serge Semin Sept. 20, 2020, 11 a.m. UTC
It has been discovered that on our MIPS P5600-based CPU the IO accessors
aren't that rapid as they could be even taking into account a relatively
slow AXI2APB bridge embedded into the system interconnect. Turned out we
can introduce two types of optimizations. First we can remove the
execution barriers from the relaxed IO-accessors as our CPU conforms to
the MIPS Coherency Protocol Specification [1, 2]. Of course it also
concerns the IO interconnect implementation. So in accordance with [3] we
suggest to remove the barriers at least for the platforms which conform
the specification the same way as ours. Second there is a dedicated
Coherency Manager control register, which can be also used to tune the IO
methods up. For some reason it hasn't been added to the MIPS arch code so
far, while it provides flags for instance to speed the SYNC barrier for
the platforms with non-re-ordering IO interconnect, to set the cache ops
serialization limits, enable the speculative reads, etc. For now we
suggest to add just the macro with the CM2 GCR_CONTROL register accessors
and fields description. So any platform could use it to activate the
corresponding optimization. Our platform-wise we'll do this in the
framework of our Baikal-T1 platform code in the prom_init() method.

[1] MIPS Coherence Protocol Specification, Document Number: MD00605,
    Revision 01.01. September 14, 2015, 4.2 Execution Order Behavior,
    p. 33

[2] MIPS Coherence Protocol Specification, Document Number: MD00605,
    Revision 01.01. September 14, 2015, 4.8.1 IO Device Access, p. 58

[3] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt,
Section "KERNEL I/O BARRIER EFFECTS"

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (2):
  mips: Add strong UC ordering config
  mips: Introduce MIPS CM2 GCR Control register accessors

 arch/mips/Kconfig               |  8 ++++++++
 arch/mips/include/asm/io.h      | 20 ++++++++++----------
 arch/mips/include/asm/mips-cm.h | 15 +++++++++++++++
 3 files changed, 33 insertions(+), 10 deletions(-)

Comments

Serge Semin Sept. 29, 2020, 9:12 p.m. UTC | #1
Thomas,
Any comment on the series? The changes aren't that comprehensive, so it would
be great to merge it in before the 5.10 merge window is opened.

-Sergey

On Sun, Sep 20, 2020 at 02:00:08PM +0300, Serge Semin wrote:
> It has been discovered that on our MIPS P5600-based CPU the IO accessors
> aren't that rapid as they could be even taking into account a relatively
> slow AXI2APB bridge embedded into the system interconnect. Turned out we
> can introduce two types of optimizations. First we can remove the
> execution barriers from the relaxed IO-accessors as our CPU conforms to
> the MIPS Coherency Protocol Specification [1, 2]. Of course it also
> concerns the IO interconnect implementation. So in accordance with [3] we
> suggest to remove the barriers at least for the platforms which conform
> the specification the same way as ours. Second there is a dedicated
> Coherency Manager control register, which can be also used to tune the IO
> methods up. For some reason it hasn't been added to the MIPS arch code so
> far, while it provides flags for instance to speed the SYNC barrier for
> the platforms with non-re-ordering IO interconnect, to set the cache ops
> serialization limits, enable the speculative reads, etc. For now we
> suggest to add just the macro with the CM2 GCR_CONTROL register accessors
> and fields description. So any platform could use it to activate the
> corresponding optimization. Our platform-wise we'll do this in the
> framework of our Baikal-T1 platform code in the prom_init() method.
> 
> [1] MIPS Coherence Protocol Specification, Document Number: MD00605,
>     Revision 01.01. September 14, 2015, 4.2 Execution Order Behavior,
>     p. 33
> 
> [2] MIPS Coherence Protocol Specification, Document Number: MD00605,
>     Revision 01.01. September 14, 2015, 4.8.1 IO Device Access, p. 58
> 
> [3] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt,
> Section "KERNEL I/O BARRIER EFFECTS"
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Maciej W. Rozycki <macro@linux-mips.org>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> Serge Semin (2):
>   mips: Add strong UC ordering config
>   mips: Introduce MIPS CM2 GCR Control register accessors
> 
>  arch/mips/Kconfig               |  8 ++++++++
>  arch/mips/include/asm/io.h      | 20 ++++++++++----------
>  arch/mips/include/asm/mips-cm.h | 15 +++++++++++++++
>  3 files changed, 33 insertions(+), 10 deletions(-)
> 
> -- 
> 2.27.0
>
Thomas Bogendoerfer Sept. 30, 2020, 10:15 a.m. UTC | #2
On Wed, Sep 30, 2020 at 12:12:32AM +0300, Serge Semin wrote:
> Thomas,
> Any comment on the series? The changes aren't that comprehensive, so it would
> be great to merge it in before the 5.10 merge window is opened.

for the both patches there is no user for it, so I don't see a reason
to apply it.

Thomas.
Serge Semin Sept. 30, 2020, 1:23 p.m. UTC | #3
On Wed, Sep 30, 2020 at 12:15:32PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Sep 30, 2020 at 12:12:32AM +0300, Serge Semin wrote:
> > Thomas,
> > Any comment on the series? The changes aren't that comprehensive, so it would
> > be great to merge it in before the 5.10 merge window is opened.
> 
> for the both patches there is no user for it, so I don't see a reason
> to apply it.

@Thomas. I see your point. I'll merge them into my repo with Baikal-T1 CSP/BSP
patches and will deliver all at once when the kernel is ready to accept the
changes (most likely in 3 - 5 months).

@Jiaxun, if you've any hardware which for sure supports the strong UC
ordering, feel free to submit a patchset which activates the proposed here
config together with my STRONG_UC_ORDERING-alteration applied before your
changes.

-Sergey

> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]