Messages in this thread | | | Date | Mon, 20 Mar 2017 11:52:15 +0000 | From | Will Deacon <> | Subject | Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64 |
| |
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
| |