From: "Christian König" <christian.koenig@amd.com>
To: Christoph Hellwig <hch@infradead.org>,
John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Daniel Vetter <daniel@ffwll.ch>,
Sumit Semwal <sumit.semwal@linaro.org>,
Liam Mark <lmark@codeaurora.org>,
Chris Goldsworthy <cgoldswo@codeaurora.org>,
Laura Abbott <labbott@kernel.org>,
Brian Starkey <Brian.Starkey@arm.com>,
Hridya Valsaraju <hridya@google.com>,
Suren Baghdasaryan <surenb@google.com>,
Sandeep Patil <sspatil@google.com>,
Daniel Mentz <danielmentz@google.com>,
??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@vger.kernel.org, dri-devel@lists.freedesktop.org,
Mel Gorman <mgorman@suse.de>,
linux-mm@kvack.org
Subject: Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation
Date: Wed, 7 Jul 2021 09:10:26 +0200 [thread overview]
Message-ID: <afea8c13-ef8d-7eb1-c362-8d6d1649751d@amd.com> (raw)
In-Reply-To: <YOVL1f4m+8ly9fyM@infradead.org>
Am 07.07.21 um 08:38 schrieb Christoph Hellwig:
> On Wed, Jun 30, 2021 at 01:34:17AM +0000, John Stultz wrote:
>> This adds a shrinker controlled page pool, extracted
>> out of the ttm_pool logic, and abstracted out a bit
>> so it can be used by other non-ttm drivers.
> Can you explain in detail why you need a differnt page pool over the one
> maintained by the page allocator? Fragmenting the memory into all kinds
> of pools has lots of downsides, so the upsides need to be explained in
> detail.
Well, the original code all this is based on already had the comment
that this really belong into the page allocator.
The key point is traditionally only GPUs used uncached and
write-combined memory in such large quantities that having a pool for
them makes sense.
Because of this we had this separately to reduce the complexity in the
page allocator to handle another set of complexity of allocation types.
For the upside, for those use cases it means huge performance
improvements for those drivers. See the numbers John provided in the
cover letter.
But essentially at least I would be totally fine moving this into the
page allocator, but moving it outside of TTM already helps with this
goal. So this patch set is certainly a step into the right direction.
Regards,
Christian.
next prev parent reply other threads:[~2021-07-07 7:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 1:34 [PATCH v9 0/5] Generic page pool & deferred freeing for system dmabuf hea John Stultz
2021-06-30 1:34 ` [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation John Stultz
2021-06-30 9:10 ` Christian König
2021-06-30 22:24 ` John Stultz
2021-07-01 6:52 ` Christian König
2021-07-06 21:03 ` John Stultz
2021-07-06 21:15 ` Daniel Vetter
2021-07-06 21:19 ` John Stultz
2021-07-07 6:52 ` Christian König
2021-07-07 6:38 ` page pools, was " Christoph Hellwig
2021-07-07 7:10 ` Christian König [this message]
2021-07-07 7:14 ` Christoph Hellwig
2021-07-07 9:32 ` Christian König
2021-07-07 19:42 ` John Stultz
2021-07-07 19:35 ` John Stultz
2021-07-08 4:20 ` Christoph Hellwig
2021-07-08 7:37 ` Christian König
2021-06-30 1:34 ` [PATCH v9 2/5] drm: ttm_pool: Rework ttm_pool to use drm_page_pool John Stultz
2021-06-30 5:11 ` kernel test robot
2021-06-30 1:34 ` [PATCH v9 3/5] dma-buf: system_heap: Add drm pagepool support to system heap John Stultz
2021-06-30 4:34 ` kernel test robot
2021-06-30 5:25 ` kernel test robot
2021-06-30 1:34 ` [PATCH v9 4/5] dma-buf: heaps: Add deferred-free-helper library code John Stultz
2021-06-30 1:34 ` [PATCH v9 5/5] dma-buf: system_heap: Add deferred freeing to the system heap John Stultz
2021-06-30 9:13 ` [PATCH v9 0/5] Generic page pool & deferred freeing for system dmabuf hea Christian König
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=afea8c13-ef8d-7eb1-c362-8d6d1649751d@amd.com \
--to=christian.koenig@amd.com \
--cc=Brian.Starkey@arm.com \
--cc=cgoldswo@codeaurora.org \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=danielmentz@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ezequiel@collabora.com \
--cc=hch@infradead.org \
--cc=hridya@google.com \
--cc=jajones@nvidia.com \
--cc=john.stultz@linaro.org \
--cc=labbott@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lmark@codeaurora.org \
--cc=mgorman@suse.de \
--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 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).