From: Vlastimil Babka <vbabka@suse.cz> To: Nicolas Boichat <drinkcat@chromium.org> Cc: robin.murphy@arm.com, will.deacon@arm.com, joro@8bytes.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, mhocko@suse.com, mgorman@techsingularity.net, yehs1@lenovo.com, rppt@linux.vnet.ibm.com, linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>, iommu@lists.linux-foundation.org, lkml <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, yong.wu@mediatek.com, Matthias Brugger <matthias.bgg@gmail.com>, tfiga@google.com, yingjoe.chen@mediatek.com, Alexander.Levin@microsoft.com Subject: Re: [PATCH RFC 1/3] mm: When CONFIG_ZONE_DMA32 is set, use DMA32 for SLAB_CACHE_DMA Date: Fri, 9 Nov 2018 13:14:41 +0100 [thread overview] Message-ID: <8f58b778-f8ef-d32e-8803-2a20f171a0b1@suse.cz> (raw) In-Reply-To: <CANMq1KB84Lpe_QbiuaKaBOwSsYr9Cis-gv5xpXaV5qjU=ON=7w@mail.gmail.com> On 11/9/18 12:57 PM, Nicolas Boichat wrote: > On Fri, Nov 9, 2018 at 6:43 PM Vlastimil Babka <vbabka@suse.cz> wrote: >> Also I'm probably missing the point of this all. In patch 3 you use >> __get_dma32_pages() thus __get_free_pages(__GFP_DMA32), which uses >> alloc_pages, thus the page allocator directly, and there's no slab >> caches involved. > > __get_dma32_pages fixes level 1 page allocations in the patch 3. > > This change fixes level 2 page allocations > (kmem_cache_zalloc(data->l2_tables, gfp | GFP_DMA)), by transparently > remapping GFP_DMA to an underlying ZONE_DMA32. > > The alternative would be to create a new SLAB_CACHE_DMA32 when > CONFIG_ZONE_DMA32 is defined, but then I'm concerned that the callers > would need to choose between the 2 (GFP_DMA or GFP_DMA32...), and also > need to use some ifdefs (but maybe that's not a valid concern?). > >> It makes little sense to involve slab for page table >> allocations anyway, as those tend to be aligned to a page size (or >> high-order page size). So what am I missing? > > Level 2 tables are ARM_V7S_TABLE_SIZE(2) => 1kb, so we'd waste 3kb if > we allocated a full page. Oh, I see. Well, I think indeed the most transparent would be to support SLAB_CACHE_DMA32. The callers of kmem_cache_zalloc() would then need not add anything special to gfp, as that's stored internally upon kmem_cache_create(). Of course SLAB_BUG_MASK would no longer have to treat __GFP_DMA32 as unexpected. It would be unexpected when passed to kmalloc() which doesn't have special dma32 caches, but for a cache explicitly created to allocate from ZONE_DMA32, I don't see why not. I'm somewhat surprised that there wouldn't be a need for this earlier, so maybe I'm still missing something. > Thanks, >
WARNING: multiple messages have this Message-ID (diff)
From: vbabka@suse.cz (Vlastimil Babka) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC 1/3] mm: When CONFIG_ZONE_DMA32 is set, use DMA32 for SLAB_CACHE_DMA Date: Fri, 9 Nov 2018 13:14:41 +0100 [thread overview] Message-ID: <8f58b778-f8ef-d32e-8803-2a20f171a0b1@suse.cz> (raw) In-Reply-To: <CANMq1KB84Lpe_QbiuaKaBOwSsYr9Cis-gv5xpXaV5qjU=ON=7w@mail.gmail.com> On 11/9/18 12:57 PM, Nicolas Boichat wrote: > On Fri, Nov 9, 2018 at 6:43 PM Vlastimil Babka <vbabka@suse.cz> wrote: >> Also I'm probably missing the point of this all. In patch 3 you use >> __get_dma32_pages() thus __get_free_pages(__GFP_DMA32), which uses >> alloc_pages, thus the page allocator directly, and there's no slab >> caches involved. > > __get_dma32_pages fixes level 1 page allocations in the patch 3. > > This change fixes level 2 page allocations > (kmem_cache_zalloc(data->l2_tables, gfp | GFP_DMA)), by transparently > remapping GFP_DMA to an underlying ZONE_DMA32. > > The alternative would be to create a new SLAB_CACHE_DMA32 when > CONFIG_ZONE_DMA32 is defined, but then I'm concerned that the callers > would need to choose between the 2 (GFP_DMA or GFP_DMA32...), and also > need to use some ifdefs (but maybe that's not a valid concern?). > >> It makes little sense to involve slab for page table >> allocations anyway, as those tend to be aligned to a page size (or >> high-order page size). So what am I missing? > > Level 2 tables are ARM_V7S_TABLE_SIZE(2) => 1kb, so we'd waste 3kb if > we allocated a full page. Oh, I see. Well, I think indeed the most transparent would be to support SLAB_CACHE_DMA32. The callers of kmem_cache_zalloc() would then need not add anything special to gfp, as that's stored internally upon kmem_cache_create(). Of course SLAB_BUG_MASK would no longer have to treat __GFP_DMA32 as unexpected. It would be unexpected when passed to kmalloc() which doesn't have special dma32 caches, but for a cache explicitly created to allocate from ZONE_DMA32, I don't see why not. I'm somewhat surprised that there wouldn't be a need for this earlier, so maybe I'm still missing something. > Thanks, >
next prev parent reply other threads:[~2018-11-09 12:14 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-09 8:24 [PATCH RFC 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables Nicolas Boichat 2018-11-09 8:24 ` Nicolas Boichat 2018-11-09 8:24 ` [PATCH RFC 1/3] mm: When CONFIG_ZONE_DMA32 is set, use DMA32 for SLAB_CACHE_DMA Nicolas Boichat 2018-11-09 8:24 ` Nicolas Boichat 2018-11-09 10:43 ` Vlastimil Babka 2018-11-09 10:43 ` Vlastimil Babka 2018-11-09 11:57 ` Nicolas Boichat 2018-11-09 11:57 ` Nicolas Boichat 2018-11-09 12:14 ` Vlastimil Babka [this message] 2018-11-09 12:14 ` Vlastimil Babka 2018-11-09 8:24 ` [PATCH RFC 2/3] include/linux/gfp.h: Add __get_dma32_pages macro Nicolas Boichat 2018-11-09 8:24 ` Nicolas Boichat 2018-11-09 8:24 ` [PATCH RFC 3/3] iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging Nicolas Boichat 2018-11-09 8:24 ` Nicolas Boichat
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8f58b778-f8ef-d32e-8803-2a20f171a0b1@suse.cz \ --to=vbabka@suse.cz \ --cc=Alexander.Levin@microsoft.com \ --cc=akpm@linux-foundation.org \ --cc=cl@linux.com \ --cc=drinkcat@chromium.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=matthias.bgg@gmail.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=penberg@kernel.org \ --cc=rientjes@google.com \ --cc=robin.murphy@arm.com \ --cc=rppt@linux.vnet.ibm.com \ --cc=tfiga@google.com \ --cc=will.deacon@arm.com \ --cc=yehs1@lenovo.com \ --cc=yingjoe.chen@mediatek.com \ --cc=yong.wu@mediatek.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.