All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Brian Starkey <brian.starkey@arm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@kernel.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Sandeep Patil" <sspatil@google.com>,
	"Daniel Mentz" <danielmentz@google.com>,
	"Chris Goldsworthy" <cgoldswo@codeaurora.org>,
	"Ørjan Eide" <orjan.eide@arm.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Ezequiel Garcia" <ezequiel@collabora.com>,
	"Simon Ser" <contact@emersion.fr>,
	"James Jones" <jajones@nvidia.com>,
	linux-media <linux-media@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>, nd <nd@arm.com>
Subject: Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Date: Fri, 16 Oct 2020 11:47:44 -0700	[thread overview]
Message-ID: <CALAqxLUbL4ci4Vnwe6UM1OEFfLyirsQOr57nmx5NSe8Bb_yAwg@mail.gmail.com> (raw)
In-Reply-To: <20201008113602.n7ju2hu3j6qsaxve@DESKTOP-E1NTVVP.localdomain>

On Thu, Oct 8, 2020 at 4:36 AM Brian Starkey <brian.starkey@arm.com> wrote:
>
> Hi John,
>
> On Sat, Oct 03, 2020 at 04:02:50AM +0000, John Stultz wrote:
> > Hey All,
>
> ...
>
> >
> > I did add to this series 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 implementaiton itself.
>
> That looks like a neat approach to me. Referencing your previous
> thread, I like the separate heap (as you have done), rather than a
> generic "cached"/"noncached" flag on all heaps.
>

Sounds good! I really appreciate the feedback on this.

> > 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!
>
> Minor nit: s/detatch/detach/ on both heaps, but other than that
> you can add my r-b to patches 1-5.

Doh! Thanks for the spelling catch! Thanks again!

> As you've said, it does feel like there's some room for
> de-duplication, but that will be easier to work out once the
> implementations settle.
>
> I've a couple of comments for the uncached heap, but I'm not confident
> I understand the implications of having the non-cached alias enough to
> say if it looks OK or not.

Thanks so much!
-john

WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org>
To: Brian Starkey <brian.starkey@arm.com>
Cc: nd <nd@arm.com>, "Sandeep Patil" <sspatil@google.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Ezequiel Garcia" <ezequiel@collabora.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"James Jones" <jajones@nvidia.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@kernel.org>,
	"Chris Goldsworthy" <cgoldswo@codeaurora.org>,
	"Hridya Valsaraju" <hridya@google.com>,
	"Ørjan Eide" <orjan.eide@arm.com>,
	linux-media <linux-media@vger.kernel.org>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Daniel Mentz" <danielmentz@google.com>
Subject: Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Date: Fri, 16 Oct 2020 11:47:44 -0700	[thread overview]
Message-ID: <CALAqxLUbL4ci4Vnwe6UM1OEFfLyirsQOr57nmx5NSe8Bb_yAwg@mail.gmail.com> (raw)
In-Reply-To: <20201008113602.n7ju2hu3j6qsaxve@DESKTOP-E1NTVVP.localdomain>

On Thu, Oct 8, 2020 at 4:36 AM Brian Starkey <brian.starkey@arm.com> wrote:
>
> Hi John,
>
> On Sat, Oct 03, 2020 at 04:02:50AM +0000, John Stultz wrote:
> > Hey All,
>
> ...
>
> >
> > I did add to this series 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 implementaiton itself.
>
> That looks like a neat approach to me. Referencing your previous
> thread, I like the separate heap (as you have done), rather than a
> generic "cached"/"noncached" flag on all heaps.
>

Sounds good! I really appreciate the feedback on this.

> > 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!
>
> Minor nit: s/detatch/detach/ on both heaps, but other than that
> you can add my r-b to patches 1-5.

Doh! Thanks for the spelling catch! Thanks again!

> As you've said, it does feel like there's some room for
> de-duplication, but that will be easier to work out once the
> implementations settle.
>
> I've a couple of comments for the uncached heap, but I'm not confident
> I understand the implications of having the non-cached alias enough to
> say if it looks OK or not.

Thanks so much!
-john
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-16 18:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03  4:02 [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation John Stultz
2020-10-03  4:02 ` John Stultz
2020-10-03  4:02 ` [PATCH v3 1/7] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 2/7] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 3/7] dma-buf: heaps: Remove heap-helpers code John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 4/7] dma-buf: heaps: Skip sync if not mapped John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 5/7] dma-buf: system_heap: Allocate higher order pages if available John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 6/7] dma-buf: dma-heap: Keep track of the heap device struct John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-03  4:02 ` [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap John Stultz
2020-10-03  4:02   ` John Stultz
2020-10-05 13:45   ` Christoph Hellwig
2020-10-08  5:03     ` John Stultz
2020-10-08  5:03       ` John Stultz
2020-10-05 21:21   ` kernel test robot
2020-10-05 21:21     ` kernel test robot
2020-10-05 21:21   ` [RFC PATCH] dma-buf: system_heap: sys_uncached_heap can be static kernel test robot
2020-10-05 21:21     ` kernel test robot
2020-10-07  7:43   ` [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap Dan Carpenter
2020-10-07  7:43     ` Dan Carpenter
2020-10-07  7:43     ` Dan Carpenter
2020-10-08  5:38     ` John Stultz
2020-10-08  5:38       ` John Stultz
2020-10-08 11:51   ` Brian Starkey
2020-10-08 11:51     ` Brian Starkey
2020-10-16 19:03     ` John Stultz
2020-10-16 19:03       ` John Stultz
2020-10-16 23:15       ` John Stultz
2020-10-16 23:15         ` John Stultz
2021-01-29  1:23       ` Daniel Mentz
2021-01-29  1:23         ` Daniel Mentz
2020-10-08 11:36 ` [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation Brian Starkey
2020-10-08 11:36   ` Brian Starkey
2020-10-16 18:47   ` John Stultz [this message]
2020-10-16 18:47     ` John Stultz

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=CALAqxLUbL4ci4Vnwe6UM1OEFfLyirsQOr57nmx5NSe8Bb_yAwg@mail.gmail.com \
    --to=john.stultz@linaro.org \
    --cc=brian.starkey@arm.com \
    --cc=cgoldswo@codeaurora.org \
    --cc=contact@emersion.fr \
    --cc=danielmentz@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ezequiel@collabora.com \
    --cc=hridya@google.com \
    --cc=jajones@nvidia.com \
    --cc=labbott@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=nd@arm.com \
    --cc=orjan.eide@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sspatil@google.com \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.com \
    /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.