Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64

From: Will Deacon
Date: Mon Mar 20 2017 - 07:53:29 EST


On Tue, Mar 14, 2017 at 10:06:48PM +0800, Ding Tianhong wrote:
> On 2017/3/13 21:31, Robin Murphy wrote:
> > On 13/03/17 12:03, Ding Tianhong wrote:
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index 8c7c244..36249a3 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -115,6 +115,7 @@ config ARM64
> >> select SPARSE_IRQ
> >> select SYSCTL_EXCEPTION_TRACE
> >> select THREAD_INFO_IN_TASK
> >> + select ARCH_WANT_RELAX_ORDER
> >
> > I'd say the first order of business is to rename this config option to
> > IXBGE_82599_WANT_RELAXED_ORDER so that it's not entirely misleading and
>
> not only for 82599, including 82598, 82576....
>
> > ambiguous. At first glance it looks far more like something scary to do
> > with memory barriers than a network driver option. Howcome this isn't
> > just in drivers/net/intel/Kconfig as a "default y if SPARC" bool anyway?
>
> didn't see any essential differences, and I still need to get some Acked by arm maintainer.
>
> >
>
> Yes, more memory barriers always affect the performance especially for
> some architecture not just like sparc, any optimization should be taken seriously
> especially for aarch64.

If this is a legitimate optimisation to apply (which nobody seems to be sure
about), then I'd *much* rather it was handled entirely in the driver and
predicated on CONFIG_ARM64. I can't select ARCH_WANT_RELAX_ORDER without
some notion of what on Earth that means, and whether or not other drivers
can also use that to infer some property about the arm64 ordering model.

Will