From: Halil Pasic <pasic@linux.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Petr Tesarik <ptesarik@suse.cz>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: Is __dma_direct_alloc_pages broken on s390?
Date: Thu, 18 Jul 2019 16:27:35 +0200 [thread overview]
Message-ID: <20190718162735.1559b561.pasic@linux.ibm.com> (raw)
In-Reply-To: <20190718131059.GA18742@infradead.org>
On Thu, 18 Jul 2019 06:10:59 -0700
Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Jul 18, 2019 at 02:50:44PM +0200, Halil Pasic wrote:
> > > I wondered why the kernel works OK on my system, and it is in fact not
> > > so bad. If the first allocation fails, the kernel adds GFP_DMA and
> > > retries, so this is not fatal, but with a proper definition of
> > > ARCH_ZONE_DMA_BITS it should be possible to get success in the first
> > > attempt already, let's do it.
> > >
> > > Petr T
> >
> > I fully agree! I will post a patch that provides correct
> > ARCH_ZONE_DMA_BITS for s390.
> >
> > BTW I wonder if ARCH_ZONE_DMA_BITS can be inferred from MAX_DMA_ADDRESS,
> > and why do we need both.@Christoph, maybe you can help me understand if
> > there is a relationship between the two or not, or?
>
> MAX_DMA_ADDRESS is a bit of a weird beast which I honestly do not
> understand fully, but most of the uses in common code look a little
> bogus, and we should probably get rid of it.
Thanks!
Regards,
Halil
prev parent reply other threads:[~2019-07-18 14:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-18 7:17 Is __dma_direct_alloc_pages broken on s390? Petr Tesarik
2019-07-18 11:36 ` Heiko Carstens
2019-07-18 11:51 ` Petr Tesarik
2019-07-18 12:50 ` Halil Pasic
2019-07-18 13:10 ` Christoph Hellwig
2019-07-18 14:27 ` Halil Pasic [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=20190718162735.1559b561.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=hch@infradead.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=ptesarik@suse.cz \
/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.