[Intel-gfx] [PATCH 0/3] drm/i915/perf: add support for multi context filtering

[Chris Wilson]

Quoting Lionel Landwerlin (2020-03-30 14:14:18)
> On 27/03/2020 12:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-27 10:32:06)
> >> Hi all,
> >>
> >> i915/perf has currently support for single context filtering. This
> >> allows mesa to read the content of the OA buffer and cut out any
> >> unrelated context running in a middle of a query.
> >>
> >> Iris currently uses 2 GEM contexts for 3D & compute commands. In order
> >> to support performance queries on the compute context we need to be
> >> able to also filter on the second GEM context used for compute
> >> commands.
> >>
> >> This series add support for filtering up to 4 GEM contexts in
> >> i915/perf.
> > Why make it a fixed size? [From a quick look it's just fixed storage as
> > you use a dynamically sized array. Considered sorting and bsearching?]
> > -Chris
> 
> I figured you might not like too many contexts to be pinned.

Well if you can pin 65,356 contexts and still be able to profile, I'll
be impressed. Having things pinned will bite us [that fragmentation is
going to cause issues in the long run], but here's there's definitely a
natural limit in being able to pin everything the user requests. If we
can do that, we can likely profile their workload. Failure here will mean
that other users start seeing ENOSPC randomly (which is what we want to
avoid).

I think the first limit that will be hit will be the unique sw id space
for contexts. icl+ brings that down to 1023, minus the 3 bits we use
internally, so 127.

> Also a small size makes bsort kind of pointless ;)

Yeah, but otoh bsearch is such a small amount overhead for a small array
that unless it is very hot, I'm sure we can find other things to fill
the profiles.

> I'll see how that looks. What the goto bsort utility in the kernel?

#include <linux/sort.h>
#include <linux/bsearch.h>

I do wish the latter would have a macro generator.
-Chris