Re: [PATCH 0/4] Userptr bo slab use optimization

[Ben Widawsky <benjamin.widawsky@intel.com>]

On 17-07-27 10:25:51, Chris Wilson wrote:
>Quoting Tvrtko Ursulin (2017-07-27 10:05:00)
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Yet another attempt to get this series reviewed and merged...
>>
>> I've heard Vulkan might be creating a lot of userptr objects so might be
>> interesting to check what benefit it brings to those use cases.
>
>Optimist :) My thinking is that this should only impact get_pages ->
>vma_bind, which is supposed a rare operation, and if should happen as
>part of the steady state that we have too many sg in a chain is just one
>of the myriad little paper cuts :)
>

Vulkan is critically dependent on userptr, but I don't believe we create many
usrptr BOs as the implementation and API reduce the number of BOs in general.

I don't see any reason not to do any of this though. Series is
Acked-by: Ben Widawsky <ben@bwidawsk.net>

>> As an introduction, this allows i915 to create fewer sg table entries for the bo
>> backing store representation. As such it primarily saves kernel slab memory.
>>
>> When we added this optimisation to normal i915 bos, the savings were as far as
>> I remember around 1-2MiB of slab after booting to KDE desktop, and 2-4Mib on
>> neverball (game) main screen (or maybe it was while playing).
>
>I think we also want to think about the aspect where we are creating
>objects of multiple 1G huge pages, so we are going to run into the sg
>limits very quickly.
>-Chris

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx