From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA480C56201 for ; Thu, 12 Nov 2020 05:42:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5DC2420825 for ; Thu, 12 Nov 2020 05:42:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="F5OJ5El8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728260AbgKLFmB (ORCPT ); Thu, 12 Nov 2020 00:42:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729594AbgKLFjS (ORCPT ); Thu, 12 Nov 2020 00:39:18 -0500 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DEE1C0617A7 for ; Wed, 11 Nov 2020 21:39:17 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id s9so4666545ljo.11 for ; Wed, 11 Nov 2020 21:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Yv2Pj9PDV7sIfV/tkESHXJ55GaWZncr9TsyJJzMjRV4=; b=F5OJ5El8ZBPyveOMEas7Dvy0Ybf3roUDGX9nSKt/GvFKemsoIoZ3H3nxTqaL11T8KR MlDVCiFBTFnmPeru3luSMFilW7RDlXBpncqfJ/ik8dtbAEV+uU9O4ykTLQ0vMTK4AK+e gH+latBs+/B9MQtZspFvwfvUpkrYDZxs2VGmkbeY0hnfW5RxPJj7CTXPwZB2VPw0J8Jt xxW3Q8U1TdLhmo9/qI2QgTpEUm5KMVBFgLjEV0keuVAIEtXCqLonk+rPhj94q4KGWsR4 /REgtXQ7jepo3gGBO5gi+YAeXP6Wdk63zEsFPLdqWDoSEjIRVEjvUmNdPi91xk503wLa wPxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Yv2Pj9PDV7sIfV/tkESHXJ55GaWZncr9TsyJJzMjRV4=; b=oCPhvxWV6wqoV4o9agwns7JPsJxU4ZEqu7v0QKJasrcjBnimgdLggoKrZ2888vYHHn UGHGCvrklEjTTsCeAbjU9cEvQP0BDI/stZ1Cp07qMPA41am7AM7gi4T69jSHcE15vwVI k3P52sKcmsUl3evYCr24d+QPGRSvwyMACeu4iCeE8vJcSytl3RRtDiRGWOoEoyGlA74v m0g1IwtdzoEMOAxpcIuGHbPJDUfWJkYKbgPzJTHp5FmqxyfWAeIOiitWjnjsDD/nQnRc 2t6l8aAgZtOFkrnKJ+oeseFPjPK6UmFo9IZT2Qp+nWzRjnG5DB8nuDojlR+MXqtdZ04W l8+g== X-Gm-Message-State: AOAM532n42kxHCgkoc3hMaNDvnKv1jt09PXMGHtJGGbPLVA8htgFru2d +51+Lg9e2Fb87FEk0ieQ+XoI5e2U2tD5QLCWZymJ5w== X-Google-Smtp-Source: ABdhPJxSyeHxpGUg5+j/tG7KO7L13ECyFVZf7kpwDci8FU3UWauWNnoJj0AppaojWgSaIZqN7Vl9OOMbXqhxUKZdzIc= X-Received: by 2002:a05:651c:506:: with SMTP id o6mr11013134ljp.249.1605159555688; Wed, 11 Nov 2020 21:39:15 -0800 (PST) MIME-Version: 1.0 References: <20201110034934.70898-1-john.stultz@linaro.org> In-Reply-To: <20201110034934.70898-1-john.stultz@linaro.org> From: Sumit Semwal Date: Thu, 12 Nov 2020 11:09:04 +0530 Message-ID: Subject: Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation To: John Stultz , Daniel Vetter , Christian Koenig Cc: lkml , Liam Mark , Laura Abbott , Brian Starkey , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Daniel Mentz , Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , "open list:DMA BUFFER SHARING FRAMEWORK" , DRI mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, On Tue, 10 Nov 2020 at 09:19, John Stultz wrote: > > Hey All, > So just wanted to send my last revision of my patch series > of performance optimizations to the dma-buf system heap. Thanks very much for your patches - I think the first 5 patches look good t= o me. I know there was a bit of discussion over adding a new system-uncached heap v/s using a flag to identify that; I think I prefer the separate heap idea, but lets ask one last time if any one else has any real objections to it. Daniel, Christian: any comments from your side on this? I am planning to merge this series to drm-misc this week if I hear no objections. > > This series reworks the system heap to use sgtables, and then > consolidates the pagelist method from the heap-helpers into the > CMA heap. After which the heap-helpers logic is removed (as it > is unused). I'd still like to find a better way to avoid some of > the logic duplication in implementing the entire dma_buf_ops > handlers per heap. But unfortunately that code is tied somewhat > to how the buffer's memory is tracked. As more heaps show up I > think we'll have a better idea how to best share code, so for > now I think this is ok. > > After this, the series introduces an optimization that > =C3=98rjan Eide implemented for ION that avoids calling sync on > attachments that don't have a mapping. > > Next, an optimization to use larger order pages for the system > heap. This change brings us closer to the current performance > of the ION allocation code (though there still is a gap due > to ION using a mix of deferred-freeing and page pools, I'll be > looking at integrating those eventually). > > Finally, a reworked version of my uncached system heap > implementation I was submitting a few weeks back. Since it > duplicated a lot of the now reworked system heap code, I > realized it would be much simpler to add the functionality to > the system_heap implementation itself. > > While not improving the core allocation performance, the > uncached heap allocations do result in *much* improved > performance on HiKey960 as it avoids a lot of flushing and > invalidating buffers that the cpu doesn't touch often. > > Feedback on these would be great! > > thanks > -john > > New in v5: > * Added a comment explaining why the order sizes are > chosen as they are > > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Hridya Valsaraju > Cc: Suren Baghdasaryan > Cc: Sandeep Patil > Cc: Daniel Mentz > Cc: Chris Goldsworthy > Cc: =C3=98rjan Eide > Cc: Robin Murphy > Cc: Ezequiel Garcia > Cc: Simon Ser > Cc: James Jones > Cc: linux-media@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > > John Stultz (7): > dma-buf: system_heap: Rework system heap to use sgtables instead of > pagelists > dma-buf: heaps: Move heap-helper logic into the cma_heap > implementation > dma-buf: heaps: Remove heap-helpers code > dma-buf: heaps: Skip sync if not mapped > dma-buf: system_heap: Allocate higher order pages if available > dma-buf: dma-heap: Keep track of the heap device struct > dma-buf: system_heap: Add a system-uncached heap re-using the system > heap > > drivers/dma-buf/dma-heap.c | 33 +- > drivers/dma-buf/heaps/Makefile | 1 - > drivers/dma-buf/heaps/cma_heap.c | 324 +++++++++++++++--- > drivers/dma-buf/heaps/heap-helpers.c | 270 --------------- > drivers/dma-buf/heaps/heap-helpers.h | 53 --- > drivers/dma-buf/heaps/system_heap.c | 494 ++++++++++++++++++++++++--- > include/linux/dma-heap.h | 9 + > 7 files changed, 753 insertions(+), 431 deletions(-) > delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c > delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h > > -- > 2.17.1 > Thanks much, Best, Sumit.