All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Christoph Hellwig <hch@lst.de>,
	iommu@lists.linux-foundation.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection
Date: Fri, 28 Sep 2018 17:46:26 +0200	[thread overview]
Message-ID: <20180928154626.GA10234@lst.de> (raw)
In-Reply-To: <514bd29960cb1573ead2f3956f18e1cbaa5f32f7.camel@kernel.crashing.org>

On Fri, Sep 28, 2018 at 10:06:48AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> > On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > > I'm not sure this is entirely right.
> > > 
> > > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > > fail if you allocate something above 1G (which is legit for
> > > ZONE_DMA32).
> > 
> > And then we will try GFP_DMA further down in the function:
> > 
> > 		if (IS_ENABLED(CONFIG_ZONE_DMA) &&
> > 		    dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> > 		    !(gfp & GFP_DMA)) {
> > 			gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> > 			goto again;
> > 		}
> > 
> > This is and old optimization from x86, because chances are high that
> > GFP_DMA32 will give you suitable memory for the infamous 31-bit
> > dma mask devices (at least at boot time) and thus we don't have
> > to deplete the tiny ZONE_DMA pool.
> 
> I see, it's rather confusing :-) Wouldn't it be better to check against
> top of 32-bit memory instead here too ?

Where is here?  In __dma_direct_optimal_gfp_mask we already handled
it due to the optimistic zone selection we are discussing.

In the fallback quoted above there is no point for it, as with a
physical memory size smaller than ZONE_DMA32 (or ZONE_DMA for that matter)
we will have succeeded with the optimistic zone selection and not hit
the fallback path.

Either way this code probably needs much better comments.  I'll send
a patch on top of the recent series.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection
Date: Fri, 28 Sep 2018 17:46:26 +0200	[thread overview]
Message-ID: <20180928154626.GA10234@lst.de> (raw)
In-Reply-To: <514bd29960cb1573ead2f3956f18e1cbaa5f32f7.camel@kernel.crashing.org>

On Fri, Sep 28, 2018 at 10:06:48AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> > On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > > I'm not sure this is entirely right.
> > > 
> > > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > > fail if you allocate something above 1G (which is legit for
> > > ZONE_DMA32).
> > 
> > And then we will try GFP_DMA further down in the function:
> > 
> > 		if (IS_ENABLED(CONFIG_ZONE_DMA) &&
> > 		    dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> > 		    !(gfp & GFP_DMA)) {
> > 			gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> > 			goto again;
> > 		}
> > 
> > This is and old optimization from x86, because chances are high that
> > GFP_DMA32 will give you suitable memory for the infamous 31-bit
> > dma mask devices (at least at boot time) and thus we don't have
> > to deplete the tiny ZONE_DMA pool.
> 
> I see, it's rather confusing :-) Wouldn't it be better to check against
> top of 32-bit memory instead here too ?

Where is here?  In __dma_direct_optimal_gfp_mask we already handled
it due to the optimistic zone selection we are discussing.

In the fallback quoted above there is no point for it, as with a
physical memory size smaller than ZONE_DMA32 (or ZONE_DMA for that matter)
we will have succeeded with the optimistic zone selection and not hit
the fallback path.

Either way this code probably needs much better comments.  I'll send
a patch on top of the recent series.

  reply	other threads:[~2018-09-28 15:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-20 18:52 dma mask related fixups (including full bus_dma_mask support) Christoph Hellwig
2018-09-20 18:52 ` [PATCH 1/5] dma-mapping: make the get_required_mask method available unconditionally Christoph Hellwig
     [not found]   ` <20180920185247.20037-2-hch-jcswGhMUV9g@public.gmane.org>
2018-09-27  1:28     ` Benjamin Herrenschmidt
2018-09-27  1:28       ` Benjamin Herrenschmidt
2018-09-20 18:52 ` [PATCH 2/5] dma-direct: add an explicit dma_direct_get_required_mask Christoph Hellwig
     [not found]   ` <20180920185247.20037-3-hch-jcswGhMUV9g@public.gmane.org>
2018-09-27  1:31     ` Benjamin Herrenschmidt
2018-09-27  1:31       ` Benjamin Herrenschmidt
2018-09-27 14:12   ` Robin Murphy
2018-09-27 15:28     ` Christoph Hellwig
     [not found]       ` <20180927152818.GC10566-jcswGhMUV9g@public.gmane.org>
2018-09-27 15:35         ` Robin Murphy
2018-09-27 15:35           ` Robin Murphy
2018-09-20 18:52 ` [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection Christoph Hellwig
     [not found]   ` <20180920185247.20037-4-hch-jcswGhMUV9g@public.gmane.org>
2018-09-27  1:45     ` Benjamin Herrenschmidt
2018-09-27  1:45       ` Benjamin Herrenschmidt
     [not found]       ` <1811156d5a1df1166c7ab7522525619b951f047d.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2018-09-27 13:49         ` Christoph Hellwig
2018-09-27 13:49           ` Christoph Hellwig
     [not found]           ` <20180927134922.GA8281-jcswGhMUV9g@public.gmane.org>
2018-09-28  0:06             ` Benjamin Herrenschmidt
2018-09-28  0:06               ` Benjamin Herrenschmidt
2018-09-28  0:06               ` Benjamin Herrenschmidt
2018-09-28 15:46               ` Christoph Hellwig [this message]
2018-09-28 15:46                 ` Christoph Hellwig
2018-09-27 14:30   ` Robin Murphy
2018-09-27 15:30     ` Christoph Hellwig
     [not found]       ` <20180927153028.GD10566-jcswGhMUV9g@public.gmane.org>
2018-09-27 15:38         ` Robin Murphy
2018-09-27 15:38           ` Robin Murphy
     [not found]           ` <2b98d7b2-bf74-ccc9-881a-a91e2c9949c3-5wv7dgnIgG8@public.gmane.org>
2018-09-27 15:41             ` Christoph Hellwig
2018-09-27 15:41               ` Christoph Hellwig
2018-09-20 18:52 ` [PATCH 4/5] dma-direct: implement complete bus_dma_mask handling Christoph Hellwig
     [not found]   ` <20180920185247.20037-5-hch-jcswGhMUV9g@public.gmane.org>
2018-09-27 14:58     ` Robin Murphy
2018-09-27 14:58       ` Robin Murphy
2018-09-27 15:32       ` Christoph Hellwig
2018-09-27 16:14         ` Robin Murphy
2018-09-27 16:14           ` Robin Murphy
     [not found]           ` <967e98b1-99ab-8f95-4c89-6156ce489b93-5wv7dgnIgG8@public.gmane.org>
2018-09-27 16:27             ` Christoph Hellwig
2018-09-27 16:27               ` Christoph Hellwig
2018-09-27 16:27               ` Christoph Hellwig
     [not found]               ` <20180927162737.GA11974-jcswGhMUV9g@public.gmane.org>
2018-09-27 16:41                 ` Robin Murphy
2018-09-27 16:41                   ` Robin Murphy
2018-09-27 16:41                   ` Robin Murphy
2018-09-20 18:52 ` [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size Christoph Hellwig
     [not found]   ` <20180920185247.20037-6-hch-jcswGhMUV9g@public.gmane.org>
2018-09-27  1:50     ` Benjamin Herrenschmidt
2018-09-27  1:50       ` Benjamin Herrenschmidt
2018-09-27 13:49       ` Christoph Hellwig
2018-09-27 15:07         ` Robin Murphy
  -- strict thread matches above, loose matches on Subject: below --
2018-09-27 22:35 dma mask related fixups (including full bus_dma_mask support) v2 Christoph Hellwig
2018-09-27 22:35 ` [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig

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=20180928154626.GA10234@lst.de \
    --to=hch@lst.de \
    --cc=benh@kernel.crashing.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.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: link
Be 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.