On Tue, Feb 9, 2021 at 6:46 PM Christian König <christian.koenig@xxxxxxx> wrote: > > > > Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan: > > On Tue, Feb 9, 2021 at 4:57 AM Christian König <christian.koenig@xxxxxxx> 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.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fstaging%2Fandroid%2Fion%2Fion_page_pool.c%3Fh%3Dv5.10%23n28&data=04%7C01%7Cchristian.koenig%40amd.com%7Cdccccff8edcd4d147a5b08d8cd20cff2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637484888114923580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9%2BIBC0tezSV6Ci4S3kWfW%2BQvJm4mdunn3dF6C0kyfCw%3D&reserved=0 > >>>> > >>>> > >>>> 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. > > Yeah, that's what I see here as well. But exactly that is utterly nonsense. > > Those pages are not "free" in the sense that get_free_page could return > them directly. Well on Android that is kinda true, because Android has it's oom-killer (way back it was just a shrinker callback, not sure how it works now), which just shot down all the background apps. So at least some of that (everything used by background apps) is indeed reclaimable on Android. But that doesn't hold on Linux in general, so we can't really do this for common code. Also I had a long meeting with Suren, John and other googles yesterday, and the aim is now to try and support all the Android gpu memory accounting needs with cgroups. That should work, and it will allow Android to handle all the Android-ism in a clean way in upstream code. Or that's at least the plan. I think the only thing we identified that Android still needs on top is the dma-buf sysfs stuff, so that shared buffers (which on Android are always dma-buf, and always stay around as dma-buf fd throughout their lifetime) can be listed/analyzed with full detail. But aside from this the plan for all the per-process or per-heap account, oom-killer integration and everything else is planned to be done with cgroups. Android (for now) only needs to account overall gpu memory since none of it is swappable on android drivers anyway, plus no vram, so not much needed. Cheers, Daniel > > Regards, > Christian. > > > > >> In the best case this just messes up the accounting, in the worst case > >> it can cause memory corruption. > >> > >> Christian. > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel