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

Chris Wilson chris at chris-wilson.co.uk
Thu Jul 27 10:53:27 UTC 2017


Quoting Tvrtko Ursulin (2017-07-27 11:46:03)
> 
> 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.

It's definitely beneficial, no doubt. Just a new minor user isn't all
that exciting ;)

> >> 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? :)

They fortunately haven't seen ours... But yes Linus did rant about doing
2+G of dma as being wrong... Too bad. It doesn't stop it from being the
interface into dma remapping etc. :|
-Chris


More information about the Intel-gfx mailing list