[Intel-gfx] [PATCH i-g-t 03/21] trace.pl: Virtual engine support

[Tvrtko Ursulin]

On 10/05/2019 13:52, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-05-08 13:10:40)
>> From: Tvrtko Ursulin <tvrtko.ursulin at 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?

Preemption handling works in a way that it is supposed to forget request 
ever existed before the final submit and complete. (It will expand the 
timeline by showing the runnable state all until the final request_in 
and shrink the execution boxes to the time between final request_in and 
request_out.) It's yet another weakness yeah. Perhaps I was feeding 
hopes a more capable tool would replace trace.pl. Adding support to show 
preemption properly certainly sounds like a lot of work.

> 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.

Could be. The tool remained at the first approach of showing physical 
and virtual timelines separately, but the execution boxes belonging to 
virtual timeline being on physical timelines.

Perhaps another useful approach would be to shadow the execution boxes 
on the virtual timelines.

> 
>> +sub is_veng
>> +{
>> +       my ($class, $instance) = split ':', shift;
>> +
>> +       return $instance eq '254';
> 
> Ok. I thought I might have caught you out.

You have, but I've worked around it. :)

> 
>> +               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.

Oh yeah, like I said above. Could do. But perhaps some 
cleanup/refactoring should come first.

>> +
>> +                       $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?

It does that, both in stdout and html.

Regards,

Tvrtko