On 06/19/2014 04:19 PM, William Cohen wrote:
> On 06/19/2014 04:59 PM, Frank Ch. Eigler wrote:
>> William Cohen <wcohen@xxxxxxxxxx> writes:
>>
>>> I have been looking at a PMDA that provides information about how long
>>> it takes for packets to make their way from userspace to the network
>>> device and from network device to userspace. [...]
>>
>> Neat.
>>
>>> network.interface.in.latency instance "devname"
>>> network.interface.out.latency instance "devname"
>>> [...]
>>> (latency_sum[t]-latency_sum[t-delta])/(packets[t]-packets[t-delta])
>>
>> This sounds like just the sort of thing that we'd use dsmith's richer
>> pcp-systemtap interface widgetry, currently being designed, and this
>> computation could be one of its examples. Keep the ideas coming, and
>> work with dsmith. (I would not suggest building just this into a
>> separate PMDA.)
>>
>>
>> - FChE
>>
>
> Hi Frank,
>
> Is the a pointer to the pcp/systemtap integration that David Smith
> is working on?
At this point most of it is in my head. But, here's the original plan
(although "plan" is probably too strong a word at this point). The plan
is for stap to provide dynamic values to pcp. This would be a lot like
pcp's mmv library/pmda, that allows pcp to monitor memory mapped values
from a program. In this case, systemtap would be providing the values.
Note that it probably won't end up 100% compatible with pcp's mmv
library/pmda.
(In a perfect world, perhaps systemtap's dyninst side could actually use
pcp's mmv library. I'd hope to make things look the same from the user's
point of view inside systemtap.)
> It is possible that similar latency measurements could be done for
> the block io layer like the stuff that blktrace does. However, one
> concern is there could be a huge number of items to track (in the
> tens of thousands) that might not fit easily in a default sized
> associative array.
Here's where things get interesting. I mentioned this "plan" to Nathan,
and he suggested we might need to go further. If we're going to provide
real tracing information back to pcp, we're going to need to provide
timestamp'ed information, read on demand from pcp. This means we'd need
to buffer it inside systemtap. This might be a phase 2.
Back to your original idea for a second. Are you at the point where
you've got a systemtap script that produces the data you want? If so,
I'd love to see it and use it for a test when I get to that point.
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|