This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Measure the Accept Queueing Time


peterzbach wrote:

> [...]
> Most everything inside the kernel is a queue or system of queues, but
> as Frank noted, the trick is to find the proper probe points to
> measure them.

> As for queues, the only three useful measurements are average
> service time, average wait time, and average queue length. [...]
> The most useful way to measure these values in a lightweight way was
> detailed by Adrian Cockcroft about a decade ago [...]

Thanks for the reference.  I put a simplified first sketch of this
into a new "queue_stats.stp" tapset.  It comes with an accompanying
pass-5 test case / demo that simulates six concurrent threads modeling
traffic to two separate queues.

% stap ../tests/testsuite/systemtap.samples/queue_demo.stp
block-read: 9 ops/s, 1.191 qlen, 207754 await, 81453 svctm, 74% wait, 51% util
block-write: 8 ops/s, 0.785 qlen, 224397 await, 132798 svctm, 56% wait, 72% util
block-read: 9 ops/s, 0.882 qlen, 215635 await, 122062 svctm, 63% wait, 75% util
block-write: 8 ops/s, 1.010 qlen, 237468 await, 119600 svctm, 68% wait, 67% util
block-read: 10 ops/s, 0.741 qlen, 158623 await, 88998 svctm, 54% wait, 66% util
block-write: 9 ops/s, 0.997 qlen, 188266 await, 88399 svctm, 76% wait, 68% util


The new code provides these generic calculations only.  The client
code must still plop probes into the appropriate place (say, in the
block I/O stack, or the scheduler's run queue, or ...?) and call the
provided queue state-change tracking functions.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]