[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac459cbf03c343ecad78450d89f340e7@AcuMS.aculab.com>
Date: Fri, 24 Nov 2017 10:35:56 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jaewon Kim' <jaewon31.kim@...sung.com>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"hch@....de" <hch@....de>,
"robin.murphy@....com" <robin.murphy@....com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mhocko@...e.com" <mhocko@...e.com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jaewon31.kim@...il.com" <jaewon31.kim@...il.com>
Subject: RE: [RFC v2] dma-coherent: introduce no-align to avoid allocation
failure and save memory
From: Jaewon Kim
> Sent: 24 November 2017 05:59
>
> dma-coherent uses bitmap APIs which internally consider align based on the
> requested size. If most of allocations are small size like KBs, using
> alignment scheme seems to be good for anti-fragmentation. But if large
> allocation are commonly used, then an allocation could be failed because
> of the alignment. To avoid the allocation failure, we had to increase total
> size.
>
> This is a example, total size is 30MB, only few memory at front is being
> used, and 9MB is being requsted. Then 9MB will be aligned to 16MB. The
> first try on offset 0MB will be failed because others already are using
> them. The second try on offset 16MB will be failed because of ouf of bound.
>
> So if the alignment is not necessary on a specific dma-coherent memory
> region, we can set no-align property. Then dma-coherent will ignore the
> alignment only for the memory region.
ISTM that the alignment needs to be a property of the request, not of the
device. Certainly the device driver code is most likely to know the specific
alignment requirements of any specific allocation.
We've some hardware that would need large allocations to be 16k aligned.
We actually use multiple 16k allocations because any large buffers are
accessed directly from userspace (mmap and vm_iomap_memory) and the
card has its own page tables (with 16k pages).
David
Powered by blists - more mailing lists