Thread (8 messages) 8 messages, 3 authors, 2021-07-08

Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation

From: John Stultz <hidden>
Date: 2021-07-07 19:42:55
Also in: dri-devel, linux-media, lkml

On Wed, Jul 7, 2021 at 12:15 AM Christoph Hellwig [off-list ref] wrote:
On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote:
quoted
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.
Unless I'm badly misreading the patch and this series there is nothing
about cache attributes in this code.  It just allocates pages, zeroes
them, eventually hands them out to a consumer and registers a shrinker
for its freelist.

If OTOH it actually dealt with cachability that should be documented
in the commit log and probably also the naming of the implementation.
So the cache attributes are still managed in the tmm_pool code. This
series just pulls the pool/shrinker management out into common code so
we can use it in the dmabuf heap code without duplicating things.

thanks
-john
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help