[PATCH 0/2] mips: Introduce some IO-accessors optimizations
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 Cc: Alexey Malahov Cc: Pavel Parkhomenko Cc: Vadim Vlasov Cc: Maciej W. Rozycki Cc: linux-m...@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
Re: [PATCH 0/2] mips: Introduce some IO-accessors optimizations
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. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 0/2] mips: Introduce some IO-accessors optimizations
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 ]
Re: [PATCH 0/2] mips: Introduce some IO-accessors optimizations
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 > Cc: Alexey Malahov > Cc: Pavel Parkhomenko > Cc: Vadim Vlasov > Cc: Maciej W. Rozycki > Cc: linux-m...@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 >
