From: Christoph Hellwig <hch@lst.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: David Rientjes <rientjes@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-mm@kvack.org,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-rpi-kernel <linux-rpi-kernel@lists.infradead.org>
Subject: Re: [BUG] XHCI getting ZONE_DMA32 memory > than its bus_dma_limit
Date: Tue, 7 Jul 2020 08:55:49 +0200 [thread overview]
Message-ID: <20200707065549.GA23760@lst.de> (raw)
In-Reply-To: <32ee3bf222b1966caa98b67a9cec8712817a4b52.camel@suse.de>
On Mon, Jul 06, 2020 at 04:09:36PM +0200, Nicolas Saenz Julienne wrote:
> On Sun, 2020-07-05 at 16:41 -0700, David Rientjes wrote:
> > On Fri, 3 Jul 2020, Robin Murphy wrote:
> > > Or perhaps just get rid of atomic_pool_dma32 (and allocate atomic_pool_dma
> > > from ZONE_DMA32 if !ZONE_DMA). That should make it fall pretty much back in
> > > line while still preserving the potential benefit of the kernel pool for
> > > non-address-constrained devices.
> > >
> >
> > I assume it depends on how often we have devices where
> > __dma_direct_alloc_pages() behavior is required, i.e. what requires the
> > dma_coherent_ok() checks and altering of the gfp flags to get memory that
> > works.
> >
> > Is the idea that getting rid of atomic_pool_dma32 would use GFP_KERNEL
> > (and atomic_pool_kernel) as the default policy here? That doesn't do any
> > dma_coherent_ok() checks so dma_direct_alloc_pages would return from
> > ZONE_NORMAL without a < 3G check?
>
> IIUC this is not what Robin proposes.
>
> The idea is to only have one DMA pool, located in ZONE_DMA, if enabled, and
> ZONE_DMA32 otherwise. This way you're always sure the memory is going to be
> good enough for any device while maintaining the benefits of
> atomic_pool_kernel.
That is how I understood the proposal from Robin and I think it is
the right thing to do.
> > It *seems* like we want to check if dma_coherent_ok() succeeds for ret in
> > dma_direct_alloc_pages() when allocating from the atomic pool and, based
> > on criteria that allows fallback, just fall into
> > __dma_direct_alloc_pages()?
>
> I suspect I don't have enough perspective here but, isn't that breaking the
> point of having an atomic pool? Wouldn't that generate big latency spikes? I
> can see how audio transfers over USB could be affected by this specifically,
> IIRC those are allocated atomically and have timing constraints.
>
> That said, if Robin solution works for you, I don't mind having a go at it.
We can't just fall back to __dma_direct_alloc_pages when allocation
from the atomic pool fails, as the atomic pool exists for provide
allocations that require sleeping actions for callers that can't
sleep.
prev parent reply other threads:[~2020-07-07 6:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 17:49 [BUG] XHCI getting ZONE_DMA32 memory > than its bus_dma_limit Jeremy Linton
2020-07-03 14:53 ` Nicolas Saenz Julienne
2020-07-03 17:42 ` Robin Murphy
2020-07-05 23:41 ` David Rientjes
2020-07-06 14:09 ` Nicolas Saenz Julienne
2020-07-07 6:55 ` Christoph Hellwig [this message]
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=20200707065549.GA23760@lst.de \
--to=hch@lst.de \
--cc=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=rientjes@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).