Comment # 11 on bug 1204380 from Vlastimil Babka

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_HARDWALL|__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?

CCing tzimmermann.