[Intel-gfx] Patch set to enable cache shrinking

[Chris Wilson]

On Thu, 2009-06-11 at 14:45 +0800, Shaohua Li wrote:
> It appears all gem object pages are dirty, as userspace always writes gem object first
> and then execute some gpu ins. For a dirty page, i915_gem_object_unbind can't help.
> shmem dirty pages must be swapped out and then they can be freed.

Indeed I took your suggestions and looked at the interaction with
obj_priv->dirty. Clearing this flag as appropriate seems to be effective
- except that the kernel is still struggling to fit in >600MB of bo on a
512MB swapless box and triggers the OOM killer rather simply reporting
ENOMEM. I haven't determined just who is at fault (it may simply be that
the working set is larger than RAM). My local patches work much harder
to evict swap buffers which did improve the recovery process, but still
the replay dies under firefox-36.

> But as userspace is caching GEM object, it knows which object's content is useless.
> When kernel gets such info, kernel can free dirty gem object's page without swap.
> 
> I'll sent out two reference patches to demonstrate the idea. Maybe they can be
> integrated into your patches.

Thanks, I'll see if they improve the situation for me. My immediate
observation, and my fault since I didn't mention it, is that the
retained flag was returned so that could implement
APPLE_object_purgeable on top of the ioctl and for the bo-cache means we
can remove any objects that have lost their backing pages and thus are
no longer part of an effective cache (which was absent in the libdrm
patch I sent, oops!).
-ickle