linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Starkey <brian.starkey@arm.com>
To: Cho KyongHo <pullip.cho@samsung.com>
Cc: Hyesoo Yu <hyesoo.yu@samsung.com>,
	sumit.semwal@linaro.org, minchan@kernel.org,
	akpm@linux-foundation.org, iamjoonsoo.kim@lge.com,
	joaodias@google.com, linux-mm@kvack.org, surenb@google.com,
	vbabka@suse.cz, afd@ti.com, benjamin.gaignard@linaro.org,
	lmark@codeaurora.org, labbott@redhat.com, john.stultz@linaro.org,
	christian.koenig@amd.com, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	devicetree@vger.kernel.org, nd@arm.com
Subject: Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
Date: Wed, 19 Aug 2020 14:22:04 +0100	[thread overview]
Message-ID: <20200819132204.2rki3xsczdy2cpsk@DESKTOP-E1NTVVP.localdomain> (raw)
In-Reply-To: <20200819034626.GB70898@KEI>

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

Cheers,
-Brian

  reply	other threads:[~2020-08-19 13:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200818074547epcas2p21e0c2442873d03800c7bc2c3e76405d6@epcas2p2.samsung.com>
2020-08-18  8:04 ` [PATCH 0/3] Chunk Heap Support on DMA-HEAP Hyesoo Yu
     [not found]   ` <CGME20200818074550epcas2p1e12121bc6e38086277766f08a59767ff@epcas2p1.samsung.com>
2020-08-18  8:04     ` [PATCH 1/3] dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps Hyesoo Yu
     [not found]   ` <CGME20200818074553epcas2p240c2129fb8186f53e03abb0a0725461c@epcas2p2.samsung.com>
2020-08-18  8:04     ` [PATCH 2/3] dma-buf: heaps: add chunk heap to dmabuf heaps Hyesoo Yu
2020-08-18 10:11       ` David Hildenbrand
     [not found]   ` <CGME20200818074554epcas2p2702e648ba975ea6fbe33c84396b152a9@epcas2p2.samsung.com>
2020-08-18  8:04     ` [PATCH 3/3] dma-heap: Devicetree binding for chunk heap Hyesoo Yu
2020-08-18 16:48       ` Rob Herring
2020-08-21  8:21         ` Hyesoo Yu
2020-08-18 10:55   ` [PATCH 0/3] Chunk Heap Support on DMA-HEAP Brian Starkey
2020-08-19  3:46     ` Cho KyongHo
2020-08-19 13:22       ` Brian Starkey [this message]
2020-08-21  7:38         ` Cho KyongHo
2020-08-18 20:55   ` 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=20200819132204.2rki3xsczdy2cpsk@DESKTOP-E1NTVVP.localdomain \
    --to=brian.starkey@arm.com \
    --cc=afd@ti.com \
    --cc=akpm@linux-foundation.org \
    --cc=benjamin.gaignard@linaro.org \
    --cc=christian.koenig@amd.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hyesoo.yu@samsung.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joaodias@google.com \
    --cc=john.stultz@linaro.org \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lmark@codeaurora.org \
    --cc=minchan@kernel.org \
    --cc=nd@arm.com \
    --cc=pullip.cho@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).