From: Christoph Hellwig <hch@infradead.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Robin Murphy <robin.murphy@arm.com>,
Tomasz Figa <tfiga@chromium.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Pawel Osciak <pawel@osciak.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] common: DMA-mapping: add DMA_ATTR_NOHUGEPAGE attribute
Date: Fri, 8 Jan 2016 23:55:48 -0800 [thread overview]
Message-ID: <20160109075548.GB25059@infradead.org> (raw)
In-Reply-To: <CAD=FV=W8h45qnhH-a8--fUS=ObJhBu77ZCJn2QOB5NsMoFesnA@mail.gmail.com>
On Fri, Jan 08, 2016 at 03:31:29PM -0800, Doug Anderson wrote:
> Ah, that makes so much more sense now! :) So you were suggesting
> something like DMA_ATTR_SMALL_PAGES_OK. Then you if we wanted all
> possible states you'd have 0 vs. DMA_ATTR_SMALL_PAGES_OK vs.
> DMA_ATTR_HUGE_PAGE? That would avoid the double-negative but does
> have the downside that it's less obvious that DMA_ATTR_SMALL_PAGES_OK
> is the opposite of DMA_ATTR_HUGE_PAGE.
or DMA_ATTR_4K_PAGES if that's what you want. We have at least 4k, 8k,
16k and 64k page support in the kernel, not sure if 32k and 256k ever
made it mainline. What does your hardware actually require?
This needs to be documented properly and hpefully also reflected in the
name of the fag. Otherwise we'll end up with a giant desaster like
GFP_DMA that means something slightly different on every architecture.
next prev parent reply other threads:[~2016-01-09 7:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-08 0:36 [PATCH v4 0/3] dma-mapping: Patches for speeding up allocation Douglas Anderson
2016-01-08 0:36 ` [PATCH v4 1/3] ARM: dma-mapping: Optimize allocation Douglas Anderson
2016-01-08 0:36 ` [PATCH v4 2/3] common: DMA-mapping: add DMA_ATTR_NOHUGEPAGE attribute Douglas Anderson
2016-01-08 13:10 ` Robin Murphy
2016-01-08 23:04 ` Doug Anderson
2016-01-08 13:35 ` Russell King - ARM Linux
2016-01-08 23:05 ` Doug Anderson
2016-01-08 23:18 ` Russell King - ARM Linux
2016-01-08 23:31 ` Doug Anderson
2016-01-09 7:55 ` Christoph Hellwig [this message]
2016-01-09 16:24 ` Tomasz Figa
2016-01-08 13:42 ` Christoph Hellwig
2016-01-08 23:05 ` Doug Anderson
2016-01-09 7:54 ` Christoph Hellwig
2016-01-08 0:36 ` [PATCH v4 3/3] ARM: dma-mapping: Use DMA_ATTR_NOHUGEPAGE hint to optimize allocation Douglas Anderson
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=20160109075548.GB25059@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=pawel@osciak.com \
--cc=robin.murphy@arm.com \
--cc=tfiga@chromium.org \
/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