From: Leon Romanovsky <leon@kernel•org>
To: Jason Gunthorpe <jgg@nvidia•com>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Alexander Gordeev <agordeev@linux•ibm.com>,
Andrew Morton <akpm@linux-foundation•org>,
Christian Borntraeger <borntraeger@linux•ibm.com>,
Borislav Petkov <bp@alien8•de>,
Dave Hansen <dave.hansen@linux•intel.com>,
"David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Gerald Schaefer <gerald.schaefer@linux•ibm.com>,
Vasily Gorbik <gor@linux•ibm.com>,
Heiko Carstens <hca@linux•ibm.com>,
"H. Peter Anvin" <hpa@zytor•com>,
Justin Stitt <justinstitt@google•com>,
Jakub Kicinski <kuba@kernel•org>,
linux-rdma@vger•kernel.org, linux-s390@vger•kernel.org,
llvm@lists•linux.dev, Ingo Molnar <mingo@redhat•com>,
Bill Wendling <morbo@google•com>,
Nathan Chancellor <nathan@kernel•org>,
Nick Desaulniers <ndesaulniers@google•com>,
netdev@vger•kernel.org, Paolo Abeni <pabeni@redhat•com>,
Salil Mehta <salil.mehta@huawei•com>,
Sven Schnelle <svens@linux•ibm.com>,
Thomas Gleixner <tglx@linutronix•de>,
x86@kernel•org, Yisen Zhuang <yisen.zhuang@huawei•com>,
Arnd Bergmann <arnd@arndb•de>,
linux-arch@vger•kernel.org, linux-arm-kernel@lists•infradead.org,
Mark Rutland <mark.rutland@arm•com>,
Michael Guralnik <michaelgur@mellanox•com>,
patches@lists•linux.dev, Niklas Schnelle <schnelle@linux•ibm.com>,
Jijie Shao <shaojijie@huawei•com>, Will Deacon <will@kernel•org>
Subject: Re: [PATCH v3 6/6] IB/mlx5: Use __iowrite64_copy() for write combining stores
Date: Tue, 15 Jul 2025 08:57:07 +0300 [thread overview]
Message-ID: <20250715055707.GC5882@unreal> (raw)
In-Reply-To: <20250714215504.GA2083014@nvidia.com>
On Mon, Jul 14, 2025 at 06:55:04PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 11, 2024 at 01:46:19PM -0300, Jason Gunthorpe wrote:
> > mlx5 has a built in self-test at driver startup to evaluate if the
> > platform supports write combining to generate a 64 byte PCIe TLP or
> > not. This has proven necessary because a lot of common scenarios end up
> > with broken write combining (especially inside virtual machines) and there
> > is other way to learn this information.
> >
> > This self test has been consistently failing on new ARM64 CPU
> > designs (specifically with NVIDIA Grace's implementation of Neoverse
> > V2). The C loop around writeq() generates some pretty terrible ARM64
> > assembly, but historically this has worked on a lot of existing ARM64 CPUs
> > till now.
> >
> > We see it succeed about 1 time in 10,000 on the worst effected
> > systems. The CPU architects speculate that the load instructions
> > interspersed with the stores makes the WC buffers statistically flush too
> > often and thus the generation of large TLPs becomes infrequent. This makes
> > the boot up test unreliable in that it indicates no write-combining,
> > however userspace would be fine since it uses a ST4 instruction.
>
> Hi Catalin,
>
> After a year of testing this in real systems it turns out that still
> some systems are not good enough with the unrolled 8 byte store loop.
> In my view the CPUs are quite bad here and this WC performance
> optimization is not working very well.
>
> There are only two more options to work around this issue, use the
> unrolled 16 byte STP or the single Neon instruction 64 byte store.
>
> Since STP was rejected alread we've only tested the Neon version. It
> does make a huge improvement, but it still somehow fails to combine
> rarely sometimes. The CPU is really bad at this :(
>
> So we want to make mlx5 use the single 64 byte neon store instruction
> like userspace has been using for a long time for this testing
> algorithm.
>
> It is simple enough, but the question has come up where to put the
> code. Do you want to somehow see the neon option to be in the
> arch/arm64 code or should we stick it in the driver under a #ifdef?
>
> The entry/exit from neon is slow enough I don't think any driver doing
> performance work would want to use neon instead of __iowrite64_copy(),
> so I do not think it should be hidden inside __iowrite64_copy(). Nor
> have I thought of a name for an arch generic function..
__iowrite64_slow_copy() ????
>
> Thanks,
> Jason
next prev parent reply other threads:[~2025-07-15 5:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 16:46 [PATCH v3 0/6] Fix mlx5 write combining support on new ARM64 cores Jason Gunthorpe
2024-04-11 16:46 ` [PATCH v3 1/6] x86: Stop using weak symbols for __iowrite32_copy() Jason Gunthorpe
2024-04-11 20:24 ` Arnd Bergmann
2024-04-11 16:46 ` [PATCH v3 2/6] s390: Implement __iowrite32_copy() Jason Gunthorpe
2024-04-11 16:46 ` [PATCH v3 3/6] s390: Stop using weak symbols for __iowrite64_copy() Jason Gunthorpe
2024-04-11 20:23 ` Arnd Bergmann
2024-04-11 16:46 ` [PATCH v3 4/6] arm64/io: Provide a WC friendly __iowriteXX_copy() Jason Gunthorpe
2024-04-11 16:46 ` [PATCH v3 5/6] net: hns3: Remove io_stop_wc() calls after __iowrite64_copy() Jason Gunthorpe
2024-04-11 16:46 ` [PATCH v3 6/6] IB/mlx5: Use __iowrite64_copy() for write combining stores Jason Gunthorpe
2024-04-16 8:29 ` Leon Romanovsky
2025-07-14 21:55 ` Jason Gunthorpe
2025-07-15 5:57 ` Leon Romanovsky [this message]
2025-07-15 10:15 ` Will Deacon
2025-07-15 11:52 ` Jason Gunthorpe
2025-07-18 18:10 ` Catalin Marinas
2025-07-18 20:00 ` Jason Gunthorpe
2024-04-23 0:18 ` [PATCH v3 0/6] Fix mlx5 write combining support on new ARM64 cores Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250715055707.GC5882@unreal \
--to=leon@kernel$(echo .)org \
--cc=agordeev@linux$(echo .)ibm.com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=arnd@arndb$(echo .)de \
--cc=borntraeger@linux$(echo .)ibm.com \
--cc=bp@alien8$(echo .)de \
--cc=catalin.marinas@arm$(echo .)com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=gerald.schaefer@linux$(echo .)ibm.com \
--cc=gor@linux$(echo .)ibm.com \
--cc=hca@linux$(echo .)ibm.com \
--cc=hpa@zytor$(echo .)com \
--cc=jgg@nvidia$(echo .)com \
--cc=justinstitt@google$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=linux-arch@vger$(echo .)kernel.org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-rdma@vger$(echo .)kernel.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=llvm@lists$(echo .)linux.dev \
--cc=mark.rutland@arm$(echo .)com \
--cc=michaelgur@mellanox$(echo .)com \
--cc=mingo@redhat$(echo .)com \
--cc=morbo@google$(echo .)com \
--cc=nathan@kernel$(echo .)org \
--cc=ndesaulniers@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=patches@lists$(echo .)linux.dev \
--cc=salil.mehta@huawei$(echo .)com \
--cc=schnelle@linux$(echo .)ibm.com \
--cc=shaojijie@huawei$(echo .)com \
--cc=svens@linux$(echo .)ibm.com \
--cc=tglx@linutronix$(echo .)de \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=yisen.zhuang@huawei$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox