Some newbie questions

Avi Kivity avi@scylladb.com
Tue Aug 9 14:11:00 GMT 2016



On 08/09/2016 02:25 PM, Mark Wielaard wrote:
> On Tue, Aug 09, 2016 at 09:51:22AM +0300, Avi Kivity wrote:
>> On 08/08/2016 05:58 PM, David Smith wrote:
>>> 2) Your ubacktrace() call in the timer function isn't going to report
>>> what you want. At that point, you aren't running in the context of the
>>> process, you are running in the context of whatever kernel thread is
>>> running the timer. I'm really sure what a user backtrace will report at
>>> that point, but it certainly won't be useful.
>> Actually I got good backtraces when I instrumented a task to spin for 100ms.
>> I also got some bad traces, but did not investigate more.
> stap does indeed try to make this work even from a kernel context.
> See runtime/stack.c:
>
> /** Gets user space registers when available, also sets context
>   * full_uregs_p if appropriate.  Should be used instead of accessing
>   * context uregs field directly when (full) uregs are needed from
>   * kernel context.
>   */
> static struct pt_regs *_stp_get_uregs(struct context *c)
>
> But it might indeed depend on architecture and timer probe used.
>
>

I note that pid()/tid() also kept working.  A happy coincidence maybe 
(the thread was not switched out).  Maybe a per-thread timer can be added.

I'm surprised this didn't come up before.  Trying to find out why a 
function which is usually fast and very rarely slow seems to be a good 
fit for systemtap.



More information about the Systemtap mailing list