Thread (6 messages) flat view 6 messages, 4 authors, 2021-05-17

Re: [PATCH] arm64: Make ARCH_DMA_MINALIGN configurable

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2021-05-17 14:24:20

On Mon, May 17, 2021 at 03:35:39PM +0200, Arnd Bergmann wrote:
On Mon, May 17, 2021 at 2:01 PM Ard Biesheuvel [off-list ref] wrote:
quoted
On Mon, 17 May 2021 at 13:06, Catalin Marinas [off-list ref] wrote:
quoted
On Mon, May 17, 2021 at 09:43:32AM +0200, Vincent Whitchurch wrote:

Another option I recall discussing with Arnd about two years ago was to
start with the default 128 at boot but add the smaller slab caches
later, once we have more information. This can be just another 64 byte
cache or even go all the way down to 8 byte if all the devices are
cache coherent.
ARCH_SLAB_MINALIGN is also used to statically align (members of)
struct types, so doing this at runtime is going to have limited
effect.

If a) ThunderX is the only platform we care about (do we?) that has
128 byte cachelines, and b) DMA is cache coherent on such platforms,
couldn't we separate ARCH_SLAB_MINALIGN from ARCH_DMA_MINALIGN? I.e.,
set the first to 64 and keep the second at 128?
What is the purpose of ARCH_DMA_MINALIGN then? If it's cache
coherent, does DMA buffer still need to be aligned to the cache line
size?
For coherent DMA, we don't need the alignment from a correctness
perspective.

For performance, a driver can always pass SLAB_HWCACHE_ALIGN which ends
up using cache_line_size(), so it gets the actual hardware value.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help