On Thu, Dec 5, 2013 at 2:40 AM, Volkin, Bradley D <bradley.d.volkin@xxxxxxxxx> wrote: >> > Ok, I'll look at the hw context code for buffer mgmt. For "purgeable", just via the >> > madv field in the i915 gem object? >> >> Yeah, though I'd extract two tiny helpers (maybe shared with the madvise >> ioctl) to set an object to purgeable and then resurrect it. The later can >> obviously fail. The helpers are just so we have a place to throw debug >> asserts into, maybe there are other needs for in-kernel caches. > > Hmm. Not sure how much use the helpers would be. The ioctl has one case where it will > truncate() the object, but beyond that it just sets madv appropriately. In general, > purging and resurrecting appear to happen via a put_pages() from the shrinker and a > get_pages() the next time the object is needed. Yeah, the helper would be indeed minimal. But they'd allow us to shovel checks like obj->pin_count or similar stuff in there to sanity-check users. > Also, I haven't looked too closely at the shrinker code. Could there be potential races > between the shrinker purging a buffer and an execbuf call choosing it? I would expect > that synchronization is already in place. Just curious if you know off the top of your head. As long as you try to set the object back to WILLNEED before you start using it and free your reference if that fails (i.e. it's state is PURGED) then the magic just happens. I just reviewed the code a bit and it seems like we're missing a few sanity checks and don't properly reject purgeable objects in e.g. bind_to_vm. For marking the object purgeable you only have to take care to do that after its on the active list. The shrinker will then make sure to wait for the gpu to complete processing before it drops the backing storage. Misordering here would be caught by a obj->pin_count check, hence why I've suggested that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
