Re: [igt-dev] [PATCH i-g-t 03/21] trace.pl: Virtual engine support

Chris Wilson
2019-05-10T12:52:39Z

Quoting Tvrtko Ursulin (2019-05-08 13:10:40)
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Add virtual/queue timelines to both stdout and HTML output.
>
> A new timeline is created for each queue/virtual engine to display
> associated requests in queued and runnable states. Once requests are
> submitted to a real engine for executing they show up on the physical
> engine timeline.

How does it cope with preemption events that shift the request onto
another engine?

Queues. So why are virtual engines treated differently, from my pov it's
just a timeline like any other, the only difference is that it my
execute on a different engine? My expectation would have been that
tracking would have been timeline centric.

However, I think I am confusing my perspective of timelines in the
kernel with the visualisation timelines.

> +sub is_veng
> +{
> + my ($class, $instance) = split ':', shift;
> +
> + return $instance eq '254';

Ok. I thought I might have caught you out.

> + unless (exists $queue{$key}) {
> + # Virtual engine
> + my $vkey = db_key(VENG, $ctx, $seqno);
> + my %req;
> +
> + die unless exists $queues{$ctx};
> + die unless exists $queue{$vkey};
> + die unless exists $submit{$vkey};
> +
> + # Create separate request record on the queue timeline
> + $q = $queue{$vkey};
> + $s = $submit{$vkey};
> + $req{'queue'} = $q;
> + $req{'submit'} = $s;
> + $req{'start'} = $time;
> + $req{'end'} = $time;
> + $req{'ring'} = VENG;
> + $req{'seqno'} = $seqno;
> + $req{'ctx'} = $ctx;
> + $req{'name'} = $ctx . '/' . $seqno;
> + $req{'global'} = $tp{'global'};
> + $req{'port'} = $tp{'port'};

Just quietly thinking why not adopt this for each timeline; create a
on-engine event box for all.

> +
> + $vdb{$vkey} = \%req;
> + } else {
> + $q = $queue{$key};
> + $s = $submit{$key};
> + }
>
> $req{'start'} = $time;
> $req{'ring'} = $ring;

> sub stdio_stats
> {
> my ($stats, $group, $id) = @_;
> + my $veng = exists $stats->{'virtual'} ? 1 : 0;
> my $str;
>
> - $str = 'Ring' . $group . ': ';
> + $str = $veng ? 'Virtual' : 'Ring';
> + $str .= $group . ': ';
> $str .= $stats->{'count'} . ' batches, ';
> - $str .= sprintf('%.2f (%.2f) avg batch us, ', $stats->{'avg'}, $stats->{'total-avg'});
> - $str .= sprintf('%.2f', $stats->{'idle'}) . '% idle, ';
> - $str .= sprintf('%.2f', $stats->{'busy'}) . '% busy, ';
> + unless ($veng) {
> + $str .= sprintf('%.2f (%.2f) avg batch us, ',
> + $stats->{'avg'}, $stats->{'total-avg'});
> + $str .= sprintf('%.2f', $stats->{'idle'}) . '% idle, ';
> + $str .= sprintf('%.2f', $stats->{'busy'}) . '% busy, ';
> + }
> +
> $str .= sprintf('%.2f', $stats->{'runnable'}) . '% runnable, ';
> $str .= sprintf('%.2f', $stats->{'queued'}) . '% queued, ';
> $str .= sprintf('%.2f', $stats->{'wait'}) . '% wait';

So I'm looking that the utilisation, trying to figure out why veng
matters? Do we not breakdown utilisation for the real engines, plus
utilisation on each client timeline?
-Chris