Re: [PATCH v3 00/13] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8

From: Isaac Manjarres <isaacmanjarres@google.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@lst.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ardb@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Alasdair Kergon <agk@redhat.com>, Daniel Vetter <daniel@ffwll.ch>,
	Joerg Roedel <joro@8bytes.org>, Mark Brown <broonie@kernel.org>,
	Mike Snitzer <snitzer@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-mm@kvack.org, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	Petr Tesarik <petrtesarik@huaweicloud.com>
Subject: Re: [PATCH v3 00/13] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8
Date: Tue, 16 May 2023 11:19:22 -0700	[thread overview]
Message-ID: <ZGPJKq5ME2r6KIFt@google.com> (raw)
In-Reply-To: <ZGO7L9EyDEXU6zWf@arm.com>

On Tue, May 16, 2023 at 06:19:43PM +0100, Catalin Marinas wrote:
> On Mon, May 15, 2023 at 12:09:12PM -0700, Isaac Manjarres wrote:
> > Hey Catalin, just following up on this. I think it might be worthwhile
> > to split this series into two series:
> > 
> > Series 1: Decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN,
> > and use the cacheline size to determine the minimum kmalloc
> > alignment.
> > 
> > Series 2: Lower the minimum kmalloc alignment to 8 bytes by adding
> > support for using SWIOTLB to bounce unaligned kmalloc buffers for DMA
> > transactions.
> 
> I attempted "series 1" some time ago and the discussion led to the
> combined approach (i.e. don't bother with limiting kmalloc minimum
> alignment to cache_line_size() but instead bounce those small buffers).
> In my series, I still have this fallback in case there's no swiotlb
> buffer.

> I'll post a new series this week (including DMA bouncing) but I'll try
> to move the bouncing towards the end of the series in case there are
> more discussions around this, at least the first part could be picked
> up.

Thanks Catalin! I think restructuring the series as you're suggesting
makes sense. At least being able to pick up the first part of the series
would be great, since it will have a positive impact on the memory
footprint for a lot of devices. This also helps alleviate some of the
memory overhead for devices that move from a 32-bit ARM kernel to a
64-bit ARM kernel.

The second part can continue to be refined until the SWIOTLB and IOMMU bounce
buffering refactor is complete.

-Isaac