From: m.szyprowski@samsung.com (Marek Szyprowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation
Date: Thu, 07 Jan 2016 14:52:32 +0100 [thread overview]
Message-ID: <568E6DA0.4000201@samsung.com> (raw)
In-Reply-To: <1452109005-19517-1-git-send-email-dianders@chromium.org>
Hello,
On 2016-01-06 20:36, Douglas Anderson wrote:
> This series of 3 patches will speed up memory allocation in dma-mapping
> quite a bit.
>
> The first patch ("ARM: dma-mapping: Optimize allocation") is hopefully
> not terribly controversial: it merely doesn't try as hard to allocate
> big chunks once it gets the first failure. Since it's unlikely that
> further big chunks will help (they're not likely to be virtually aligned
> anyway), this should give a big speedup with no real regression to speak
> of. Yes, things could be made better, but this seems like a sane start.
>
> The second patch ("common: DMA-mapping: add DMA_ATTR_SEQUENTIAL
> attribute") models MADV_SEQUENTIAL as I understand it. Hopefully folks
> are happy with following that lead. It does nothing by itself.
>
> The third patch ("ARM: dma-mapping: Use DMA_ATTR_SEQUENTIAL hint to
> optimize allocation") simply applies the 2nd patch. Again it's pretty
> simple. ...and again it does nothing by itself.
>
> Notably missing from this series is the fourth patch that adds teeth to
> the second and third. You can find that out of tree at
> <https://chromium-review.googlesource.com/#/c/320498/>. Unfortunately
> the rk3288_vpu, which is what I'm working on, is out of tree.
>
> All testing was done on the chromeos kernel-3.14. Sanity (compile /
> boot) testing was done on a v4.4-rc6-based kernel.
>
> Also note that v2 of this series had an extra patch
> <https://patchwork.kernel.org/patch/7888861/> that would attempt to sort
> the allocation results to opportunistically get some extra alignment. I
> dropped that, but it could be re-introduced if there was interest. I
> found that it did give a little extra alignment sometimes, but maybe not
> enough to justify the extra complexity. It also was a bit half-baked
> since it really should have tried harder to ensure alignment.
>
> Changes in v3:
> - add DMA_ATTR_SEQUENTIAL attribute new for v3
> - Use DMA_ATTR_SEQUENTIAL hint patch new for v3.
>
> Changes in v2:
> - No longer just 1 page at a time, but gives up higher order quickly.
> - Only tries important higher order allocations that might help us.
>
> Douglas Anderson (3):
> ARM: dma-mapping: Optimize allocation
> common: DMA-mapping: add DMA_ATTR_SEQUENTIAL attribute
> ARM: dma-mapping: Use DMA_ATTR_SEQUENTIAL hint to optimize allocation
>
> Documentation/DMA-attributes.txt | 11 +++++++++++
> arch/arm/mm/dma-mapping.c | 41 ++++++++++++++++++++++++++--------------
> include/linux/dma-attrs.h | 1 +
> 3 files changed, 39 insertions(+), 14 deletions(-)
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Douglas Anderson <dianders@chromium.org>,
Russell King <linux@arm.linux.org.uk>
Cc: Robin Murphy <robin.murphy@arm.com>,
Tomasz Figa <tfiga@chromium.org>, Pawel Osciak <pawel@osciak.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
laurent.pinchart+renesas@ideasonboard.com, corbet@lwn.net,
mike.looijmans@topic.nl, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, will.deacon@arm.com,
penguin-kernel@i-love.sakura.ne.jp, carlo@caione.org,
akpm@linux-foundation.org, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation
Date: Thu, 07 Jan 2016 14:52:32 +0100 [thread overview]
Message-ID: <568E6DA0.4000201@samsung.com> (raw)
In-Reply-To: <1452109005-19517-1-git-send-email-dianders@chromium.org>
Hello,
On 2016-01-06 20:36, Douglas Anderson wrote:
> This series of 3 patches will speed up memory allocation in dma-mapping
> quite a bit.
>
> The first patch ("ARM: dma-mapping: Optimize allocation") is hopefully
> not terribly controversial: it merely doesn't try as hard to allocate
> big chunks once it gets the first failure. Since it's unlikely that
> further big chunks will help (they're not likely to be virtually aligned
> anyway), this should give a big speedup with no real regression to speak
> of. Yes, things could be made better, but this seems like a sane start.
>
> The second patch ("common: DMA-mapping: add DMA_ATTR_SEQUENTIAL
> attribute") models MADV_SEQUENTIAL as I understand it. Hopefully folks
> are happy with following that lead. It does nothing by itself.
>
> The third patch ("ARM: dma-mapping: Use DMA_ATTR_SEQUENTIAL hint to
> optimize allocation") simply applies the 2nd patch. Again it's pretty
> simple. ...and again it does nothing by itself.
>
> Notably missing from this series is the fourth patch that adds teeth to
> the second and third. You can find that out of tree at
> <https://chromium-review.googlesource.com/#/c/320498/>. Unfortunately
> the rk3288_vpu, which is what I'm working on, is out of tree.
>
> All testing was done on the chromeos kernel-3.14. Sanity (compile /
> boot) testing was done on a v4.4-rc6-based kernel.
>
> Also note that v2 of this series had an extra patch
> <https://patchwork.kernel.org/patch/7888861/> that would attempt to sort
> the allocation results to opportunistically get some extra alignment. I
> dropped that, but it could be re-introduced if there was interest. I
> found that it did give a little extra alignment sometimes, but maybe not
> enough to justify the extra complexity. It also was a bit half-baked
> since it really should have tried harder to ensure alignment.
>
> Changes in v3:
> - add DMA_ATTR_SEQUENTIAL attribute new for v3
> - Use DMA_ATTR_SEQUENTIAL hint patch new for v3.
>
> Changes in v2:
> - No longer just 1 page at a time, but gives up higher order quickly.
> - Only tries important higher order allocations that might help us.
>
> Douglas Anderson (3):
> ARM: dma-mapping: Optimize allocation
> common: DMA-mapping: add DMA_ATTR_SEQUENTIAL attribute
> ARM: dma-mapping: Use DMA_ATTR_SEQUENTIAL hint to optimize allocation
>
> Documentation/DMA-attributes.txt | 11 +++++++++++
> arch/arm/mm/dma-mapping.c | 41 ++++++++++++++++++++++++++--------------
> include/linux/dma-attrs.h | 1 +
> 3 files changed, 39 insertions(+), 14 deletions(-)
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2016-01-07 13:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 19:36 [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation Douglas Anderson
2016-01-06 19:36 ` Douglas Anderson
2016-01-06 19:36 ` [PATCH v3 1/3] ARM: dma-mapping: Optimize allocation Douglas Anderson
2016-01-06 19:36 ` Douglas Anderson
2016-01-06 19:36 ` [PATCH v3 2/3] common: DMA-mapping: add DMA_ATTR_SEQUENTIAL attribute Douglas Anderson
2016-01-06 19:36 ` [PATCH v3 3/3] ARM: dma-mapping: Use DMA_ATTR_SEQUENTIAL hint to optimize allocation Douglas Anderson
2016-01-06 19:36 ` Douglas Anderson
2016-01-07 13:52 ` Marek Szyprowski [this message]
2016-01-07 13:52 ` [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation Marek Szyprowski
2016-01-07 17:23 ` Doug Anderson
2016-01-07 17:23 ` Doug 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=568E6DA0.4000201@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=linux-arm-kernel@lists.infradead.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 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.