This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: measuring accept queueing time (revisited)
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Eric Wong <normalperson at yhbt dot net>
- Cc: systemtap at sourceware dot org
- Date: Fri, 30 Nov 2012 12:32:21 -0500
- Subject: Re: measuring accept queueing time (revisited)
- References: <20121130030608.GA15285@dcvr.yhbt.net>
Hi, Eric -
normalperson (we'll just see about that :-) wrote:
> Hi all, I'm wondering if there's an updated/better version of
> the [script] posted here:
>
> http://sourceware.org/ml/systemtap/2006-q1/msg00385.html
>
> I can probably figure it out on my own, but would like to avoid
> doing so if somebody's already done the work :)
Yeah, some changes since then:
- data structures are more easily traversed by pure
script code -> and @cast type operators
- the kernel has useful tracepoints compiled in for more events,
**but** this does not currently seem to include any interesting
tcp/network/socket stuff
- the translator has gotten better placing probes
- the compiler has gotten better at generating debug data to let
us find data
So these days, I'd try to go for intercepting the inline functions
probe kernel.function("sk_acceptq_added") {
/* record $sk, timestamp */
}
probe kernel.function("sk_acceptq_removed") {
/* match $sk */
/* record elapsed time, execname(), pid() */
}
or their (source-code-reading-determined) callers.
And perhaps try to raise a flag on lkml to get some tracepoints into
the tcp/ip layer pretty please.
> [...] I'd also like to be able to get the same accept queueing time
> for Unix sockets, too.
There doesn't seem to be much queuing logic in UNIX sockets, for the
connect/accept path at least.
- FChE