linux-kernel - Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP

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: <20200821073813.GA190335@KEI>
Date:   Fri, 21 Aug 2020 16:38:13 +0900
From:   Cho KyongHo <pullip.cho@...sung.com>
To:     Brian Starkey <brian.starkey@....com>
Cc:     Hyesoo Yu <hyesoo.yu@...sung.com>, sumit.semwal@...aro.org,
        minchan@...nel.org, akpm@...ux-foundation.org,
        iamjoonsoo.kim@....com, joaodias@...gle.com, linux-mm@...ck.org,
        surenb@...gle.com, vbabka@...e.cz, afd@...com,
        benjamin.gaignard@...aro.org, lmark@...eaurora.org,
        labbott@...hat.com, john.stultz@...aro.org,
        christian.koenig@....com, linux-media@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        devicetree@...r.kernel.org, nd@....com
Subject: Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP

Hi Brain,

On Wed, Aug 19, 2020 at 02:22:04PM +0100, Brian Starkey wrote:
> Hi KyongHo,
> 
> On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> > I have seriously considered CPA in our product but we developed our own
> > because of the pool in CPA.
> 
> Oh good, I'm glad you considered it :-)
> 
> > The high-order pages are required by some specific users like Netflix
> > app. Moreover required number of bytes are dramatically increasing
> > because of high resolution videos and displays in these days.
> > 
> > Gathering lots of free high-order pages in the background during
> > run-time means reserving that amount of pages from the entier available
> > system memory. Moreover the gathered pages are soon reclaimed whenever
> > the system is sufferring from memory pressure (i.e. camera recording,
> > heavy games).
> 
> Aren't these two things in contradiction? If they're easily reclaimed
> then they aren't "reserved" in any detrimental way. And if you don't
> want them to be reclaimed, then you need them to be reserved...
> 
> The approach you have here assigns the chunk of memory as a reserved
> CMA region which the kernel is going to try not to use too - similar
> to the CPA pool.
> 
> I suppose it's a balance depending on how much you're willing to wait
> for migration on the allocation path. CPA has the potential to get you
> faster allocations, but the downside is you need to make it a little
> more "greedy".
> 
I understand why you think it as contradiction. But I don't think so.
Kernel page allocator now prefers free pages in CMA when allocating
movable pages by commit
https://lore.kernel.org/linux-mm/CAAmzW4P6+3O_RLvgy_QOKD4iXw+Hk3HE7Toc4Ky7kvQbCozCeA@mail.gmail.com/
.

We are trying to reduce unused pages to improve performance. So, unused
pages in a pool should be easily reclaimed. That is why we does not
secure free pages in a special pool for a specific usecase. Instead we
have tried to reduce performance bottle-necks in page migration to
allocate large amount memory when the memory is needed.