linux-kernel - Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201008113602.n7ju2hu3j6qsaxve@DESKTOP-E1NTVVP.localdomain>
Date:   Thu, 8 Oct 2020 12:36:02 +0100
From:   Brian Starkey <brian.starkey@....com>
To:     John Stultz <john.stultz@...aro.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Laura Abbott <labbott@...nel.org>,
        Hridya Valsaraju <hridya@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>,
        Daniel Mentz <danielmentz@...gle.com>,
        Chris Goldsworthy <cgoldswo@...eaurora.org>,
        Ørjan Eide <orjan.eide@....com>,
        Robin Murphy <robin.murphy@....com>,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Simon Ser <contact@...rsion.fr>,
        James Jones <jajones@...dia.com>, linux-media@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, nd@....com
Subject: Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap
 & a system-uncached implementation

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.

> 
> 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.

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.

Cheers!
-Brian