[Intel-gfx] Patch set to enable cache shrinking

[Shaohua Li]

On Thu, Jun 11, 2009 at 03:19:30PM +0800, Chris Wilson wrote:
> 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.
cleaning obj_priv->dirty might break something. There are two cases:
1. application has gem_bo reference
2. libdrm cache has gem_bo reference

If it's the first case, the bo might be dirty but we can't free the bo, as
application still takes the object and the object isn't controlled by libdrm.
If an object is only in libdrm cache, then we can free it.

Thanks,
Shaohua