On 27/07/2017 10:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-27 10:05:00)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
