On 10/05/2019 13:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-08 13:10:40)
From: Tvrtko Ursulin <tvrtko.ursu...@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
