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=-5.7 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 5BCFFC4707F for ; Fri, 21 May 2021 20:08:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 415966101B for ; Fri, 21 May 2021 20:08:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231546AbhEUUJr (ORCPT ); Fri, 21 May 2021 16:09:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231805AbhEUUJp (ORCPT ); Fri, 21 May 2021 16:09:45 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8873C06138A for ; Fri, 21 May 2021 13:08:21 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id q7so30078007lfr.6 for ; Fri, 21 May 2021 13:08:21 -0700 (PDT) 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=xvfpVd2OzH4+o/D/vVDC31Zzvji7CpUDutlyGbWSS2M=; b=EbaAG9yK/DK3FcwWC04VW6QzRYN89xRqlD00mrvuESUFgBxV9HY8hkAXOyT5Lt0xpx PppMV5UTCm21S4B9qt/ncdmHkOMYb27DbVQ9WV5E09GdcFKA0hRbhSVghHeaEPPoJaSb dEcBcUUDgAw4ejb0yilsMouDiF0KWMY5GDKlYDPEhctNS87/jVTGh5VE5vDzRgUx3Q1P ImYqL0JyA4p95+SC38XbOoxlTbUyOgGY7+aBPyPpC6NgRTzAHg92siUlFxEhm3olReik 2zNUFAEeFXvA/EXlg42qs5DoJCeGPD0efucoC+esFnELqjhO9qUj2rveosnwnT78ncVZ PUhA== 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=xvfpVd2OzH4+o/D/vVDC31Zzvji7CpUDutlyGbWSS2M=; b=Di4MihDYlioq0/mAvZxrVnoUkKGeN3ooTcu/w8UuCTT2IPVFbCoBR6fWnxa2SbrDEl AdAFWKYJVvQFu/yx+ReyiuDyTXu+peAx8QnY3WZqoAlOSt1XpnBhRIRKl24X69oAiCQ3 kkQ/5GYj+yv2RjF84gkgsKeGeq/a80c+ZfCU8KDXnBrJRiANrlz/jHH+C9oDZG0ymeZW Soz6ingYkYyd0OTadr5K0nJEIbhPPlOhxSqC3L+IcBfJxAQSWwbRbTEh+qhJneEDPGua 5BCS7DZARFnE/I3zs9Vu44ITluJCjUB2VVvvVzRSBzNaw0XBFuK+1LQ2RW2b3/jIXsl1 ZYHQ== X-Gm-Message-State: AOAM533yVIOn3oqn5eHLmLUQus7KSAeLvAIn1K7Bmi+xsx012ITV2AEQ psOJV9BijcRZ4IB1igDiv4TavpeGS2BUFtcxBEfxwA== X-Google-Smtp-Source: ABdhPJwkNqh6VetR4pQ9osWleGLD8Gu670e5ZwNiJj7gabab2EtxcbnJLTI/hP8824g6eoId8EW/5PjT89tzRHZhP7w= X-Received: by 2002:a19:8083:: with SMTP id b125mr3166068lfd.204.1621627700167; Fri, 21 May 2021 13:08:20 -0700 (PDT) MIME-Version: 1.0 References: <20201110034934.70898-1-john.stultz@linaro.org> In-Reply-To: From: John Stultz Date: Fri, 21 May 2021 13:08:07 -0700 Message-ID: Subject: Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation To: Lee Jones Cc: lkml , Sumit Semwal , 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-devel , Nicolas Dufresne Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 21, 2021 at 2:40 AM Lee Jones wrote: > On Tue, 10 Nov 2020 at 03:49, John Stultz wrote: >> 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. >> > > > John, did this ever make it past v5? I don't see a follow-up. So most of these have landed upstream already. The one exception is the system-uncached heap implementation, as DanielV wanted a usecase where it was beneficial to a device with an open driver. Unfortunately this hasn't been trivial to show with the open gpu devices I have, but taking Nicolas Dufresne's note, we're looking to enable v4l2 integration in AOSP on db845c, so we can hopefully show some benefit there. The HAL integration work has been taking some time to get working though. So it's a bit blocked on that for now. thanks -john