From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Thu, 07 Jan 2016 14:52:32 +0100 Subject: [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation In-Reply-To: <1452109005-19517-1-git-send-email-dianders@chromium.org> References: <1452109005-19517-1-git-send-email-dianders@chromium.org> Message-ID: <568E6DA0.4000201@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 > . 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 > 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 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752782AbcAGNwj (ORCPT ); Thu, 7 Jan 2016 08:52:39 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:15285 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751941AbcAGNwh (ORCPT ); Thu, 7 Jan 2016 08:52:37 -0500 X-AuditID: cbfec7f4-f79026d00000418a-e1-568e6da20f57 Subject: Re: [PATCH v3 0/3] dma-mapping: Patches for speeding up allocation To: Douglas Anderson , Russell King References: <1452109005-19517-1-git-send-email-dianders@chromium.org> Cc: Robin Murphy , Tomasz Figa , Pawel Osciak , Dmitry Torokhov , 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 From: Marek Szyprowski Message-id: <568E6DA0.4000201@samsung.com> Date: Thu, 07 Jan 2016 14:52:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-version: 1.0 In-reply-to: <1452109005-19517-1-git-send-email-dianders@chromium.org> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsVy+t/xq7qLcvvCDLZMVbSYs34Nm8WDNeuZ LZ4caGe0mD71AqPF2WUH2SwOL3rBaDGx6Q6LxabH11gtFrYtYbG4vGsOm8Xty7wWXTu3sFlM efuT3WJ2yztWi4MfnrBafG79x2bx8uMJFgdBjzXz1jB6tDT3sHl0nexj8pjdcJHFY+esu+we O9euAnI7ZrJ6LN7zksnjxIzfLB6bl9R7LO6bzOrx+NdLNo8X266xeXzeJBfAF8Vlk5Kak1mW WqRvl8CV8XrNY5aCR6IVSz62MzcwHhbsYuTkkBAwkbjWNJEJwhaTuHBvPVsXIxeHkMBSRon7 t/+wQzjPGSXOL+1g7GLk4BAW8Ja4ezkFpEFEIFRi3oWPzCC2kICrxOxP95lB6pkFbjBLfJ69 iQUkwSZgKNH1tosNxOYV0JJoOtLNDDKHRUBVYuEFVZCwqECMxLbli5kgSgQlfky+B9bKKeAm sf7HdrBWZgEziS8vD7NC2PISm9e8ZZ7AKDALScssJGWzkJQtYGRexSiaWppcUJyUnmuoV5yY W1yal66XnJ+7iRESn192MC4+ZnWIUYCDUYmHtyOtN0yINbGsuDL3EKMEB7OSCK+0V1+YEG9K YmVValF+fFFpTmrxIUZpDhYlcd65u96HCAmkJ5akZqemFqQWwWSZODilGhjXdrbz72zdtpb/ 7Z6YwgKtLZUNMvNuXlLa3Huave5aCdelrnfWMX/VdM+YBvy6q6reUjHx7ultTqbTX13+V1PO 03r4cen5duGMI0ybAlUM9un++/44PEdo0ZR1C+Xfu77wmBjo18LLcviJ8LmeM2LCSyd9vBFS fC3yo86t+XldOzj/s7lMNpNSYinOSDTUYi4qTgQAngQ6sssCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 > . 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 > 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 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland