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.8 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 98E98C55ABD for ; Thu, 12 Nov 2020 09:32:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2845F21D40 for ; Thu, 12 Nov 2020 09:32:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="ClGwd9PI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727346AbgKLJco (ORCPT ); Thu, 12 Nov 2020 04:32:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725966AbgKLJcn (ORCPT ); Thu, 12 Nov 2020 04:32:43 -0500 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A602C0613D1 for ; Thu, 12 Nov 2020 01:32:42 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id h2so4665133wmm.0 for ; Thu, 12 Nov 2020 01:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=yi1OMf/gd5HyvbzJ7IKPIRAKF/of2XlvAeMy3R2I3KU=; b=ClGwd9PImy4lshiA+U9TgHm3wMtpgX29mRHTW1PJ2Z/B04KEA5sYxSwmqwHFInajPL bBgGwHoANnPrek4f/2fTZmkNXn4ZXMfy6/P/wzzDLZ0D+o59/USQC5sh8s8BLMNMRT23 2JQ2SimoqOAPzXBp9UgIXN67enji1ANRDCQMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=yi1OMf/gd5HyvbzJ7IKPIRAKF/of2XlvAeMy3R2I3KU=; b=VNTPCBSxrUG7Fp+5BvMhVjN4xTls0y8fGk6XgFFbD55rnKBmhIFVS5fj748LdKZPVP ksuknryoouKNYCwh+bPzOrSEFxKoj2tL/psyEWbll08DUKs5SQBBUeh/ZpUkQQ7GQbAZ ivuQtUB1chaa1hFJ592VvlqaZbSBNc4Ku/A9NQpqi5KPRXrsBN0dd9I+BENkHRonkzR7 v2avkxCwoSaoiVSLSFVt5qjBghNcc0aqpi0DYfeLTN+PvjHaw4YurWRef+v3Pp4fKsWK vJVT4gOj5fANSEZT9CYDH6j8bD0wm+SLQWRaE9bZJI0AcPhyHaAdE1UTEKH9Aq1KZ2fc Jm7w== X-Gm-Message-State: AOAM531k2XW6qwVxdxMD9SfZwwg4mrwE5qGdlsnlmuTc7ls6gGq9qaET c7zgr3w0Q7oy8sLQiOPPS4Wx8Q== X-Google-Smtp-Source: ABdhPJyCyDhy97NTajt/L+ZmaByBkxvp9KnxOaVEKwIx5lRydWZdS/DGH3dvRWY0NjD8L6XIb4eELw== X-Received: by 2002:a1c:2d5:: with SMTP id 204mr8871662wmc.181.1605173560677; Thu, 12 Nov 2020 01:32:40 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id g20sm5717032wmh.20.2020.11.12.01.32.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2020 01:32:39 -0800 (PST) Date: Thu, 12 Nov 2020 10:32:37 +0100 From: Daniel Vetter To: Sumit Semwal Cc: John Stultz , Daniel Vetter , Christian Koenig , lkml , Liam Mark , Laura Abbott , Brian Starkey , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Daniel Mentz , Chris Goldsworthy , =?iso-8859-1?Q?=D8rjan?= Eide , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , "open list:DMA BUFFER SHARING FRAMEWORK" , DRI mailing list Subject: Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation Message-ID: <20201112093237.GS401619@phenom.ffwll.local> Mail-Followup-To: Sumit Semwal , John Stultz , Christian Koenig , lkml , Liam Mark , Laura Abbott , Brian Starkey , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Daniel Mentz , Chris Goldsworthy , =?iso-8859-1?Q?=D8rjan?= Eide , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , "open list:DMA BUFFER SHARING FRAMEWORK" , DRI mailing list References: <20201110034934.70898-1-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > 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 to 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 do wonder a bit where the userspace stack for this all is, since tuning allocators without a full stack is fairly pointless. dma-buf heaps is a bit in a limbo situation here it feels like. Plus I'm vary of anything related to leaking this kind of stuff beyond the dma-api because dma api maintainers don't like us doing that. But personally no concern on that front really, gpus need this. It's just that we do need solid justification I think if we land this. Hence back to first point. Ideally first point comes in the form of benchmarking on android together with a mesa driver (or mesa + some v4l driver or whatever it takes to actually show the benefits, I have no idea). -Daniel > > 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 > > Ørjan 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: Ørjan 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. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch