summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2020-01-20 13:49:22 +0300
committerJani Nikula <jani.nikula@intel.com>2020-02-11 12:49:31 +0300
commit07ccd6bdafa22aacc4f72b7eb14474d0b356e6c3 (patch)
tree2ce00ad8a95c698dadb75c41c30adfd7542f0db0 /tools/perf/scripts/python/export-to-postgresql.py
parenta754012b9f2323a5d640da7eb7b095ac3b8cd012 (diff)
downloadlinux-07ccd6bdafa22aacc4f72b7eb14474d0b356e6c3.tar.xz
drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list
Currently we create a new mmap_offset for every call to mmap_offset_ioctl. This exposes ourselves to an abusive client that may simply create new mmap_offsets ad infinitum, which will exhaust physical memory and the virtual address space. In addition to the exhaustion, a very long linear list of mmap_offsets causes other clients using the object to incur long list walks -- these long lists can also be generated by simply having many clients generate their own mmap_offset. However, we can simply use the drm_vma_node itself to manage the file association (allow/revoke) dropping our need to keep an mmo per-file. Then if we keep a small rbtree of per-type mmap_offsets, we can lookup duplicate requests quickly. Fixes: cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk (cherry picked from commit 7865559872074a9ab169c87915504661d630addf) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions