[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d0d0571-be74-d9a4-4f2d-27881da2e2ed@suse.cz>
Date: Fri, 7 Dec 2018 08:25:27 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Nicolas Boichat <drinkcat@...omium.org>,
Will Deacon <will.deacon@....com>
Cc: Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Levin Alexander <Alexander.Levin@...rosoft.com>,
Huaisheng Ye <yehs1@...ovo.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Yong Wu <yong.wu@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Tomasz Figa <tfiga@...gle.com>, yingjoe.chen@...iatek.com,
hch@...radead.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v5 1/3] mm: Add support for kmem caches in DMA32 zone
On 12/7/18 7:16 AM, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> to be allocated within the first 4GB of RAM, even on 64-bit systems.
> On arm64, this is done by passing GFP_DMA32 flag to memory allocation
> functions.
>
> For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
> a full page using get_free_pages, so we considered 3 approaches:
> 1. This patch, adding support for GFP_DMA32 slab caches.
> 2. genalloc, which requires pre-allocating the maximum number of L2
> page tables (4096, so 4MB of memory).
> 3. page_frag, which is not very memory-efficient as it is unable
> to reuse freed fragments until the whole page is freed.
>
> This change makes it possible to create a custom cache in DMA32 zone
> using kmem_cache_create, then allocate memory using kmem_cache_alloc.
>
> We do not create a DMA32 kmalloc cache array, as there are currently
> no users of kmalloc(..., GFP_DMA32). These calls will continue to
> trigger a warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
>
> This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
> kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
> unnecessary).
>
> Signed-off-by: Nicolas Boichat <drinkcat@...omium.org>
Acked-by: Vlastimil Babka <vbabka@...e.cz>
Powered by blists - more mailing lists