[Intel-gfx] [PATCH 0/4] Userptr bo slab use optimization

[Tvrtko Ursulin]

On 27/07/2017 10:25, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-07-27 10:05:00)
>> From: Tvrtko Ursulin <tvrtko.ursulin at 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 :)

I did not try to sell any performance benefits. There might be some 
micro (pico?) ones due less walking and/or smaller memory footprint. But 
slab reduction is the main point. It's not a big one but why not do it 
if we can. And it also makes the userptr consistent with out other bos 
in this respect. And is simpler code in i915_gem_userptr.c.

>> 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.

You mean changing the core struct to allow larger chunks? Haven't the 
core kernel people already rolled their eyes on our sg table misuse? :)

Regards,

Tvrtko