Comment # 12 on bug 1204380 from J���rgen Gro���

(In reply to Vlastimil Babka from comment #11)
> Looks like the sorting tool is still broken. Grepping the full output for
> "shmem", I can see tons of entries like this:
> 
> Page allocated via order 0, mask
> 0x1120d2(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_HAR
> DWALL|__GFP_RECLAIMABLE), pid 2603, ts 155051094696842 ns, free_ts
> 154475925820958 ns
> PFN 12866 type Reclaimable Block 25 type Reclaimable Flags
> 0xfffffc0180014(uptodate|lru|swapbacked|unevictable|node=0|zone=1|lastcpupid=
> 0x1fffff)
>  prep_new_page+0x93/0xb0
>  get_page_from_freelist+0x19e9/0x1ce0
>  __alloc_pages+0x180/0x320
>  alloc_pages_vma+0x8b/0x260
>  shmem_alloc_page+0x3f/0x90
>  shmem_alloc_and_acct_page+0x72/0x1c0
>  shmem_getpage_gfp+0x2eb/0x870
>  shmem_read_mapping_page_gfp+0x49/0xf0
>  shmem_get_pages+0x1c6/0x600 [i915]
>  __i915_gem_object_get_pages+0x34/0x40 [i915]
>  i915_gem_set_domain_ioctl+0x2b6/0x360 [i915]
>  drm_ioctl_kernel+0xb4/0x100 [drm]
>  drm_ioctl+0x35a/0x400 [drm]
>  __x64_sys_ioctl+0x8f/0xd0
>  do_syscall_64+0x58/0x80
>  entry_SYSCALL_64_after_hwframe+0x61/0xcb
> 
> Note the 'ts' and 'free_ts' values are actually irrelevant - if a page shows
> up in page_owner dump, it is currently allocated, the filtering in the
> sorting tool is bogus. So we can simply do
> 
> > grep  __i915_gem_object_get_pages page_owner_full.txt  | wc -l
> 3080094
> 
> even if all is order-0, that amounts to 11.7GB. Comments 3 says "There were
> still more than 10GB of shared memory" so I guess that's all attributable to
> i915?

Seems to be a good guess.

PID 2603 is /usr/bin/plasmashell BTW.

Right now I have about 17GB of shared mem, and "grep
__i915_gem_object_get_pages /sys/kernel/debug/page_owner | wc -l" gives me
4259344.