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