[Intel-gfx] [PATCH v2] drm/i915: Pre-allocation of shmem pages of a GEM object
Chris Wilson
chris at chris-wilson.co.uk
Mon May 5 10:17:55 CEST 2014
On Mon, May 05, 2014 at 09:55:29AM +0530, akash.goel at intel.com wrote:
> From: Akash Goel <akash.goel at intel.com>
>
> This patch could help to reduce the time, 'struct_mutex' is kept
> locked during either the exec-buffer path or Page fault
> handling path as now the backing pages are requested from shmem layer
> without holding the 'struct_mutex'.
>
> v2: Fixed the merge issue, due to which 'exec_lock' mutex was not released.
This would be a good excuse to work on per-object locks and augmenting
i915_gem_madvise_ioctl() to grab pages. iow, add obj->mutex and use that
for guarding all obj->pages related members/operations, then add
I915_MADV_POPULATE which can run without the struct mutex.
That should provide you with the lockless get_pages and keep execbuffer
reasonably clean and fast.
Again, please think about why you are *clflushing* so many pages so
often. That is a sign of userspace bo cache failure.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list