On Tue, Nov 29, 2022 at 09:18:28AM +0000, Jonathan Cameron wrote: > On Mon, 28 Nov 2022 10:16:31 -0800 > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > Hi Jonathan, > > > > On Sun, Nov 27, 2022 at 02:41:07PM +0000, Jonathan Cameron wrote: > > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > > > > > This problem was discovered in IIO as a side effect of the discussions about > > > relaxing kmalloc alignment on arm64 and resulted in a series of large > > > patch sets. > > > > > > https://lore.kernel.org/linux-iio/20220508175712.647246-1-jic23@xxxxxxxxxx/ > > > > > > Unsurprisingly there are cases of it in other subsystems. > > > > > > The short version of this is that there are a few known arm64 chips where > > > ___cacheline_aligned enforces 64 byte alignment which is what we typically > > > want for performance optimization as the size of the L1 cache lines. > > > However, further out in the cache hierarchy we have caches with 128 byte > > > lines. Those are the ones that matter for DMA safety. > > > So we need the larger alignment guarantees of ARCH_KMALLOC_MINALIGN which > > > in this case is 128 bytes. > > > > I wonder if we could have something like ____dmasafe_aligned instead of > > sprinkling ARCH_KMALLOC_MINALIGN around? > > I agree in principle and eventually that will be ARCH_DMA_MINALIGN. > But it isn't useable yet for backports. Sorry, I do not follow. Are talking about backports because the code is broken in the mainline right now, or it will become broken when Catalin's changes land? And even if it is broken right now why can't we add #define ____dmasafe_aligned __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN))) somewhere in include/linux/cache.h? Then you can tweak it as needed independently of kmalloc alignment and without need to touch drivers again and it should be easy to backport still. Thanks. -- Dmitry
