From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f198.google.com (mail-ot0-f198.google.com [74.125.82.198]) by kanga.kvack.org (Postfix) with ESMTP id 7F42B6B0007 for ; Sat, 28 Apr 2018 15:10:59 -0400 (EDT) Received: by mail-ot0-f198.google.com with SMTP id e32-v6so3246071ote.23 for ; Sat, 28 Apr 2018 12:10:59 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id a37-v6sor1843009otj.274.2018.04.28.12.10.58 for (Google Transport Security); Sat, 28 Apr 2018 12:10:58 -0700 (PDT) MIME-Version: 1.0 References: <20180426215406.GB27853@wotan.suse.de> <20180427053556.GB11339@infradead.org> <20180427161456.GD27853@wotan.suse.de> <20180428084221.GD31684@infradead.org> <20180428185514.GW27853@wotan.suse.de> In-Reply-To: <20180428185514.GW27853@wotan.suse.de> From: Matthew Wilcox Date: Sat, 28 Apr 2018 19:10:47 +0000 Message-ID: Subject: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love Content-Type: multipart/alternative; boundary="00000000000071872f056aed61da" Sender: owner-linux-mm@kvack.org List-ID: To: "Luis R. Rodriguez" Cc: Christoph Hellwig , Dan Carpenter , Julia Lawall , linux-mm@kvack.org, mhocko@kernel.org, cl@linux.com, Jan Kara , matthew@wil.cx, x86@kernel.org, luto@amacapital.net, martin.petersen@oracle.com, jthumshirn@suse.de, broonie@kernel.org, Juergen Gross , linux-spi@vger.kernel.org, Joerg Roedel , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, "lsf-pc@lists.linux-foundation.org" --00000000000071872f056aed61da Content-Type: text/plain; charset="UTF-8" Another way we could approach this is to get rid of ZONE_DMA. Make GFP_DMA a flag which doesn't map to a zone. Rather, it redirects to a separate allocator. At boot, we hand all memory under 16MB to the DMA allocator. The DMA allocator can have a shrinker which just hands back all the memory once we're under memory pressure (if it's never had an allocation). I think we can get rid of the GFP_DMA support in slab/slub. We still need to be able to allocate pages to support bounce buffers / dma_alloc_foo, but there's really no reason to allocate sub-pages at this point. On Sat, Apr 28, 2018, 14:55 Luis R. Rodriguez, wrote: > On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote: > > On Fri, Apr 27, 2018 at 04:14:56PM +0000, Luis R. Rodriguez wrote: > > > Do we have a list of users for x86 with a small DMA mask? > > > Or, given that I'm not aware of a tool to be able to look > > > for this in an easy way, would it be good to find out which > > > x86 drivers do have a small mask? > > > > Basically you'll have to grep for calls to dma_set_mask/ > > dma_set_coherent_mask/dma_set_mask_and_coherent and their pci_* > > wrappers with masks smaller 32-bit. Some use numeric values, > > some use DMA_BIT_MASK and various places uses local variables > > or struct members to parse them, so finding them will be a bit > > more work. Nothing a coccinelle expert couldn't solve, though :) > > Thing is unless we have a specific flag used consistently I don't believe > we > can do this search with Coccinelle. ie, if we have local variables and > based on > some series of variables things are set, this makes the grammatical > expression > difficult to express. So Cocinelle is not designed for this purpose. > > But I believe smatch [0] is intended exactly for this sort of purpose, is > that > right Dan? I gave a cursory look and I think it'd take me significant time > to > get such hunt down. > > [0] https://lwn.net/Articles/691882/ > > Luis > --00000000000071872f056aed61da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another way we could approach this is to get rid of ZONE_= DMA. Make GFP_DMA a flag which doesn't map to a zone. Rather, it redire= cts to a separate allocator. At boot, we hand all memory under 16MB to the = DMA allocator. The DMA allocator can have a shrinker which just hands back = all the memory once we're under memory pressure (if it's never had = an allocation).

I think we can= get rid of the GFP_DMA support in slab/slub. We still need to be able to a= llocate pages to support bounce buffers / dma_alloc_foo, but there's re= ally no reason to allocate sub-pages at this point.

On Sat, Apr 28, 2018, 14:55 Luis R. Rod= riguez, <mcgrof@kernel.org> = wrote:
On Sat, Apr 28, 2018 at 01:4= 2:21AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 27, 2018 at 04:14:56PM +0000, Luis R. Rodriguez wrote:
> > Do we have a list of users for x86 with a small DMA mask?
> > Or, given that I'm not aware of a tool to be able to look
> > for this in an easy way, would it be good to find out which
> > x86 drivers do have a small mask?
>
> Basically you'll have to grep for calls to dma_set_mask/
> dma_set_coherent_mask/dma_set_mask_and_coherent and their pci_*
> wrappers with masks smaller 32-bit.=C2=A0 Some use numeric values,
> some use DMA_BIT_MASK and various places uses local variables
> or struct members to parse them, so finding them will be a bit
> more work.=C2=A0 Nothing a coccinelle expert couldn't solve, thoug= h :)

Thing is unless we have a specific flag used consistently I don't belie= ve we
can do this search with Coccinelle. ie, if we have local variables and base= d on
some series of variables things are set, this makes the grammatical express= ion
difficult to express.=C2=A0 So Cocinelle is not designed for this purpose.<= br>
But I believe smatch [0] is intended exactly for this sort of purpose, is t= hat
right Dan? I gave a cursory look and I think it'd take me significant t= ime to
get such hunt down.

[0] https://lwn.net/Articles/691882/

=C2=A0 Luis
--00000000000071872f056aed61da--