From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is
On Fri, Jun 14, 2019 at 04:05:33PM +0100, Robin Murphy wrote:
> That said, I don't believe this particular patch should make any
> appreciable difference - alloc_pages_exact() is still going to give back
> the same base address as the rounded up over-allocation would, and
> PAGE_ALIGN()ing the
On Fri, Jun 14, 2019 at 03:01:22PM +, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k
> > boundary?
> > It looks like you are losing the alignment parameter.
>
> The DMA API
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> Does this still guarantee that requests for 16k will not cross a 16k boundary?
> It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to start with,
and you can get not naturally
From: Christoph Hellwig
> Sent: 14 June 2019 14:47
>
> Many architectures (e.g. arm, m68 and sh) have always used exact
> allocation in their dma coherent allocator, which avoids a lot of
> memory waste especially for larger allocations. Lift this behavior
> into the generic allocator so that
