[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180211235107.GE4680@bombadil.infradead.org>
Date: Sun, 11 Feb 2018 15:51:07 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Kai Heng Feng <kai.heng.feng@...onical.com>,
Laura Abbott <labbott@...hat.com>, linux-mm@...ck.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org, James.Bottomley@...senPartnership.com,
davem@...hat.com
Subject: Re: Regression after commit 19809c2da28a ("mm, vmalloc: use
__GFP_HIGHMEM implicitly")
On Sun, Feb 11, 2018 at 04:05:15AM -0800, Matthew Wilcox wrote:
> On Sun, Feb 11, 2018 at 03:28:08AM -0800, Matthew Wilcox wrote:
> > Now, longer-term, perhaps we should do the following:
> >
> > #ifdef CONFIG_ZONE_DMA32
> > #define OPT_ZONE_DMA32 ZONE_DMA32
> > #elif defined(CONFIG_64BIT)
> > #define OPT_ZONE_DMA OPT_ZONE_DMA
> > #else
> > #define OPT_ZONE_DMA32 ZONE_NORMAL
> > #endif
>
> For consistent / coherent memory, we have an allocation function.
> But we don't have an allocation function for streaming memory, which is
> what these drivers want. They also flush the DMA memory and then access
> the memory through a different virtual mapping, which I'm not sure is
> going to work well on virtually-indexed caches like SPARC and PA-RISC
> (maybe not MIPS either?)
Perhaps I (and a number of other people ...) have misunderstood the
semantics of GFP_DMA32. Perhaps GFP_DMA32 is not "allocate memory below
4GB", perhaps it's "allocate memory which can be mapped below 4GB".
Machines with an IOMMU can use ZONE_NORMAL. Machines with no IOMMU can
choose to allocate memory with a physical address below 4GB.
After all, it has 'DMA' right there in the name. If someone's relying
on it to allocate physical memory below 4GB, they're arguably misusing it.
Powered by blists - more mailing lists