From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by kanga.kvack.org (Postfix) with ESMTP id 5C1C96B2A78 for ; Thu, 22 Nov 2018 03:26:08 -0500 (EST) Received: by mail-pf1-f197.google.com with SMTP id 75so332369pfq.8 for ; Thu, 22 Nov 2018 00:26:08 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [2607:7c80:54:e::133]) by mx.google.com with ESMTPS id j14si39066760pgg.44.2018.11.22.00.26.07 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Nov 2018 00:26:07 -0800 (PST) Date: Thu, 22 Nov 2018 00:26:02 -0800 From: Christoph Hellwig Subject: Re: [PATCH v2 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables Message-ID: <20181122082602.GB2049@infradead.org> References: <20181111090341.120786-1-drinkcat@chromium.org> <0100016737801f14-84f1265d-4577-4dcf-ad57-90dbc8e0a78f-000000@email.amazonses.com> <20181121213853.GL3065@bombadil.infradead.org> <20181122023558.GO3065@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181122023558.GO3065@bombadil.infradead.org> Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Robin Murphy , Michal Hocko , Will Deacon , Levin Alexander , linux-mm@kvack.org, Christopher Lameter , Nicolas Boichat , Huaisheng Ye , David Rientjes , yingjoe.chen@mediatek.com, Vlastimil Babka , Tomasz Figa , Mike Rapoport , Matthias Brugger , Joonsoo Kim , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Pekka Enberg , iommu@lists.linux-foundation.org, Andrew Morton , Mel Gorman On Wed, Nov 21, 2018 at 06:35:58PM -0800, Matthew Wilcox wrote: > I think you should look at using the page_frag allocator here. You can > use whatever GFP_DMA flags you like. So I actually tries to use page_frag to solve the XFS unaligned kmalloc allocations problem, and I don't think it is the right hammer for this nail (or any other nail outside of networking). The problem with the page_frag allocator is that it never reuses fragments returned to the page, but only only frees the page once all fragments are freed. This means that if you have some long(er) term allocations you are effectively creating memory leaks.