[0/3] drm/i915/perf: add support for multi context filtering

Message

Lionel Landwerlin March 27, 2020, 10:32 a.m. UTC

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.

Lionel Landwerlin (3):
  drm/i915/perf: break OA config buffer object in 2
  drm/i915/perf: prepare driver to receive multiple ctx handles
  drm/i915/perf: enable filtering on multiple contexts

 drivers/gpu/drm/i915/i915_perf.c       | 702 ++++++++++++++++---------
 drivers/gpu/drm/i915/i915_perf_types.h |  25 +-
 include/uapi/drm/i915_drm.h            |  21 +
 3 files changed, 481 insertions(+), 267 deletions(-)

--
2.26.0

Comments

Chris Wilson March 27, 2020, 10:42 a.m. UTC | #1

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

Lionel Landwerlin March 30, 2020, 1:14 p.m. UTC | #2

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.

Also a small size makes bsort kind of pointless ;)


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


-Lionel

Chris Wilson March 30, 2020, 1:28 p.m. UTC | #3

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