[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160108231806.GP19062@n2100.arm.linux.org.uk>
Date: Fri, 8 Jan 2016 23:18:06 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Doug Anderson <dianders@...omium.org>
Cc: Robin Murphy <robin.murphy@....com>,
Tomasz Figa <tfiga@...omium.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Pawel Osciak <pawel@...iak.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jonathan Corbet <corbet@....net>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 2/3] common: DMA-mapping: add DMA_ATTR_NOHUGEPAGE
attribute
On Fri, Jan 08, 2016 at 03:05:13PM -0800, Doug Anderson wrote:
> 1. I have to go and touch all existing DMA-mapping code to set
> DMA_ATTR_HUGE_PAGE. That will be a big patchset and touch more code,
> making it more likely to break something.
...
Indeed, I was actually thinking of a positive "prefer/only use/force
smaller pages" thing rather than "allow huge pages" as a way to get
rid of the "no huge pages" negative as a way to get around that.
It has the same meaning when set as DMA_ATTR_NO_HUGE_PAGE but
avoids the problem of wondering what
!dma_get_attr(DMA_ATTR_NO_HUGE_PAGE, attrs)
means.
I wasn't thinking of DMA_ATTR_HUGE_PAGE as that would certainly be
wrong when CONFIG_HAVE_DMA_ATTRS is disabled (when dma_get_attr()
always returns 0.)
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Powered by blists - more mailing lists