Re: [RFC 00/22] Gen7 batch buffer command parser

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux