space query

space query

[sscheider]

Howdy!  I am wondering if systemtap probes run in kernel or user space.  In
either case, do the probes contribute to the "run" state duration of a given
PID?  If so, which?  I'm using schedtimes.stp.
Thanks!
-- 
View this message in context: http://old.nabble.com/space-query-tp33482258p33482258.html
Sent from the Sourceware - systemtap mailing list archive at Nabble.com.

RE: space query

[Turgis, Frederic]

Hi,

Here is some information, experts will correct any mistake:
- We shall see probes like extra code of a function. So it of course adds to the duration of the thread that triggered it or was running at that time

- kernel probes (kernel functions, tracepoints, ...) execute in kernel context as they instrument kernel. They add duration to the "run" state of the pid that triggered it. For example, if you probe a syscall, each time one thread calls it, probe handling will be added to its run time. But well, it is a bit more complex as not all functions are really triggered by a thread execution

- interrupts will not really be covered by schedtimes.stp. They will "add" to currently running thread (can be idle task "swapper")

- timer probes execute in kernel context and should add "duration" to the pid that was running at that time.

- don't know for user probes

- I don't know how the transport layer impacts duration. You will see a "stapio" thread in userspace taking care of reading trace if you made any. Systemtap also wakes-up regularly to check if there is any buffer trace to output. It used to be in a workqueue (so visible as a thread), but implementation has changed.


In your case, you have "sched_switch" and "sched_wakeup" probes. This is a bit specific because code decides itself to put duration inside prev or next thread.
- Execution cost of "sched_switch" will be shared between previous and next threads as per the code. Hard to say which part shall really go to previous and which one to next but approximation is OK
- "sched_wakeup" would be like interrupts, it fires inside a running task and will add to it even if not related.



Regards
Fred

OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement - System Multimedia


>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----
> From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of sscheider
> Sent: Sunday, March 11, 2012 8:09 PM
> To: systemtap@sourceware.org
> Subject: space query
>
>
> Howdy!  I am wondering if systemtap probes run in kernel or user space.  In
> either case, do the probes contribute to the "run" state duration of a given
> PID?  If so, which?  I'm using schedtimes.stp.
> Thanks!
> --
> View this message in context: http://old.nabble.com/space-query-tp33482258p33482258.html
> Sent from the Sourceware - systemtap mailing list archive at Nabble.com.

Re: space query

[Jim Keniston]

On Sun, 2012-03-11 at 12:09 -0700, sscheider wrote:
> Howdy!  I am wondering if systemtap probes run in kernel or user space.

For both kernel probes and user-space probes, the probe handlers (i.e.,
what you specify in your stap script) run in kernel space.

However, in probes of user-space code, the probe-handling sequence may
(i.e., if the probed instruction isn't emulated) include single-stepping
a copy of the probed instruction in user space.

> In
> either case, do the probes contribute to the "run" state duration of a given
> PID?

For both kernel and user-space probes, the handler runs in the context
of the process that hit the probepoint.

> If so, which?  I'm using schedtimes.stp.
> Thanks!

Jim Keniston
IBM Linux Technology Center

Re: space query

[sscheider]

Thank you both for the help.  I believe that I understand the nature of the
thread executing the code, and the computation of the thread times in
schedtimes.stp.

Thanks again,
-- Steve
-- 
View this message in context: http://old.nabble.com/space-query-tp33482258p33524790.html
Sent from the Sourceware - systemtap mailing list archive at Nabble.com.