On Fri, 4 Apr 2025 10:01:50 +0200 Thomas Zimmermann <tzimmerm...@suse.de> wrote:
> >> In your case, vmap an pin both intent to hold the shmem pages in memory. > >> They might be build on top of the same implementation, but one should > >> not be implemented with the other because of their different meanings. > > But that's not what we do, is it? Sure, in drm_gem_shmem_vmap_locked(), > > we call drm_gem_shmem_pin_locked(), but that's an internal function to > > make sure the pages are allocated and stay around until > > drm_gem_shmem_vunmap_locked() is called. > > > > I guess we could rename pin_count into hard_refcount or > > page_residency_count or xxx_count, and change the pin/unpin_locked() > > function names accordingly, but that's just a naming detail, it doesn't > > force you to call drm_gem_pin() to vmap() your GEM, it's something we > > do internally. > > Such a rename would be much appreciated. page_residency_count seems > appropriate. On a second thought, I think I prefer 'unevictable_count/inc_unevictable()/dec_unevictable()'. But looking at the gem-vram changes you just posted, it looks like gem-shmem is not the only one to use the term 'pin' for this page pinning thing, so if we go and plan for a rename, I'd rather make it DRM-wide than gem-shmem being the outlier yet again :-).
