On 08/13/2014 10:45 AM, David Smith wrote:
> On 08/12/2014 02:09 PM, William Cohen wrote:
>> Hi All,
>>
>> I have been experimenting with the systmetap mmv support David Smith
>> has been developing in the dsmith/mmv branch of systemtap. The
>> attached script is a work-in-progress to measure the amount of time
>> packets take from getting placed in the queue to the time that the are
>> actually transmitted. The list of network devices needs to be passed
>> into the systemtap script so that it can set up instances for each of
>> the network devices. There is probably a better way of getting the
>> device names to the script, but that is done to keep things simple.
>>
>> The script creates two metrics for each device: number of packets and
>> the sum of the latency. The systemtap script provides these basic
>> metrics from the start so that the pmda could compute various rate
>> on different times scale easily using the following formula for a device
>> instance at two times (t1 and t2):
>>
>> current_latency/packet = (latency[t2]-latency[t1])/(count[t2]-count[t1])
>>
>>
>> Rather than looking up the value identifies with mmv_lookup_value()
>> the value identifiers are cached in a couple of associative arrays.
>> However, I don't know whether the overhead is a real issue with that.
>>
>> Next step will be to write the mmv pmda to read this information and
>> make it available.
>>
>> Any comments about the current code would be appreciated.
>
> Sigh.
>
> I've looked at your script. There is nothing really wrong with it in
> itself, I'm now just wondering about the whole approach. The whole mmv
> interface looks clunky when expressed this way in systemtap. Once we get
> past the setup stuff in the begin probe, the update logic in do_update()
> is just sad. (Once again this isn't really a critique of your script,
> just the interface itself.) The way your script is forced to do updates
> doesn't really work - the only way this stuff will work as designed is
> that you actually keep the values in metric values, not copy stuff from
> systemtap variables into mmv values. Otherwise we're increasing the
> problem of inconsistent values between metric values.
Hi David,
I had the same feeling that there seemed to be more setup to get mmv mapping
for systemtap that desired. The copying of the data from systemtap associative
arrays to the mmv was done to allow the use of the "<<<" operator Writing
directly into the metrics to eliminate the periodic timer update seems like a
cleaner approach. The attached version does that now. However, the
mmv_lookup_value fails if more than one network device is passed in as an
argument.
One major difference between userspace mmv and the systemtap mmv is that much
of the setup in userspace mmv is just done by static creation of structures.
This is a pretty compact format. In systemtap there needs to be multiple calls
to create similar data structures and these get pretty verbose.
Another issue I had when creating the script was the relative static creation
of the mmv. Systemtap scripts often don't have an idea of what devices are
used when the script runs and the script just makes a note in an associative
array of each device observed during the run. That enumeration of possible
values at startup is something that systemtap scripts usually don't do.
>
> With enough work, we could add some systemtap translator support and
> make this less clunky. However, I'm not sure that still solves the real
> problem here. This real script (as opposed to the fake script I've been
> using to develop) has really pointed out the problems here.
>
> Perhaps I'm being too pessimistic here.
>
> If I was looking at what you are really trying to do here, here's a
> couple of ideas:
>
> - Use systemtap's procfs interface and write/modify a PCP PMDA to
> collect data from it. The advantage here is that PCP can ask to read the
> data at whatever interval it wants (1 second, 5 seconds, 1 hour, etc.)
> and the data wouldn't be computed until then (and the data would always
> be consistent).
The procfs approach was what I was thinking previously. The updates to the mmv
fields in the systemtap script are non-atomic and there is the potential to
have new and values that wouldn't exist in the procfs approach. I guess one
of the problems in the past with groking proc information was the rather free
form text. Maybe the systemtap procfs could output data in the json, xml, or
some other easily machine digestible format.
>
> - A full-blown event exporter (JSON?) from systemtap. I believe Nathan
> has outlined this in the past.
>
-Will
net_xmit_mmv.stp
Description: Text document
|