On Thu, Aug 06, 2020 at 01:50:29PM +0200, Nicolas Saenz Julienne wrote:
> > The latter is pretty much what I expect, as we only support the default and
> > per-device DMA CMAs.
>
> Fair enough, should I send a v3 with everything cleaned-up/rebased, or you'd
> rather pick it up from your version?
On Thu, 2020-08-06 at 07:18 +0200, Christoph Hellwig wrote:
> On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote:
> > > Second I don't see the need (and actually some harm) in preventing
> > > GFP_KERNEL
> > > allocations from dipping into lower CMA areas - something that we
On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote:
> > Second I don't see the need (and actually some harm) in preventing
> > GFP_KERNEL
> > allocations from dipping into lower CMA areas - something that we did
> > support
> > before 5.8 with the single pool.
>
> My
On Tue, 2020-08-04 at 08:06 +0200, Christoph Hellwig wrote:
> On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote:
> > + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
> > + return end <= DMA_BIT_MASK(zone_dma_bits);
> > + if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote:
> + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
> + return end <= DMA_BIT_MASK(zone_dma_bits);
> + if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
> + return end <=
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
-
