On Tue, Feb 9, 2021 at 4:57 AM Christian König christian.koenig@amd.com wrote:
Am 09.02.21 um 13:11 schrieb Christian König:
[SNIP]
+void drm_page_pool_add(struct drm_page_pool *pool, struct page *page) +{
spin_lock(&pool->lock);list_add_tail(&page->lru, &pool->items);pool->count++;atomic_long_add(1 << pool->order, &total_pages);spin_unlock(&pool->lock);mod_node_page_state(page_pgdat(page),NR_KERNEL_MISC_RECLAIMABLE,
1 << pool->order);Hui what? What should that be good for?
This is a carryover from the ION page pool implementation: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel...
My sense is it helps with the vmstat/meminfo accounting so folks can see the cached pages are shrinkable/freeable. This maybe falls under other dmabuf accounting/stats discussions, so I'm happy to remove it for now, or let the drivers using the shared page pool logic handle the accounting themselves?
Intentionally separated the discussion for that here.
As far as I can see this is just bluntly incorrect.
Either the page is reclaimable or it is part of our pool and freeable through the shrinker, but never ever both.
IIRC the original motivation for counting ION pooled pages as reclaimable was to include them into /proc/meminfo's MemAvailable calculations. NR_KERNEL_MISC_RECLAIMABLE defined as "reclaimable non-slab kernel pages" seems like a good place to account for them but I might be wrong.
In the best case this just messes up the accounting, in the worst case it can cause memory corruption.
Christian.