per-entity statistics

[Frank Ch. Eigler]

Martin Peschke <mp3@de.ibm.com> writes:

> [...]  First, certain data, like request latencies, is most useful
> if being provided per device, or per LUN respectively, I guess.
> [...] I could imagine an array in order to be able to store data for
> each LUN separately.  Would this approach work if I want to maintain
> more than a single counter per LUN?

> Looks like going this path might result in an array of arrays, say,
> an array of latency histograms. Is this feasible?

Systemtap arrays, like those in awk, are indexed by a tuple of key
values.  You can use device numbers, lun numbers, names, in any
consistent combination for each array.  Each array value can be either
a string, number, or statistics.

If you need to track statistics on more than one level of grouping at
a time, then use two or more arrays, with a different set of keys.

> Would it be better to maintain separate global variables for each
> LUN? Something like:
> 
> global latencies_lun1
> global latencies_lun2
> global latencies_lun3

That's not how I'd do it.  Instead, something like:

##### scsi-latencies.stp

global lun_latencies # [lun:number]
global devlun_latencies # [dev:number, lun:number]

probe scsi.latencies = kernel.function("....") {
  if (! scsi_lun_selected ($lun)) next
  lat = EXPR
  lun_latencies[$lun] <<< lat
  devlun_latencies[$dev,$lun] <<< lat
}

probe end {
  # report?
}

##### scsi-latencies-selected.stp

function scsi_lun_selected(id) { return 1 }



> [...]  Assuming I want to measure 3 LUNs attached through adapter A
> [...]  I guess, my probe would need to check everytime it has fired
> whether it's being active for a LUN to be measured before
> continueing.

That's right.

> [...]  Besides, is there a good way to pass LUN selections to a
> systemtap script? [...]

We don't yet support the equivalent of command line arguments, so the
script would indeed have to be modified.  However, if one structures
the overall script into a few parts like above, one them could contain
only the default lun-selection function.  The end-user could override
that function only using an invocation like this:

stap -I scsi-tapset/  -e '
   function scsi_lun_selected(id) { return id==1 }
   probe scsi.latencies {}
'

- FChE