Re: Accessing user-space global variables in timer.profile?

[agentzh <agentzh at gmail dot com>]

Hello!

On Mon, Apr 22, 2013 at 8:54 AM, David Smith wrote:
>
> I believe I see what you are asking here, but I'm afraid it just isn't
> possible. When we're in a process.* probe, probes run in the context of
> a process, so you can access that process' state and memory. When we're
> in a timer.* probe, probes don't really run in the context of any
> particular user process, they run in kernel context. At that point, any
> specific user process can't really be accessed. That specific user
> process might have been swapped out for instance.
>

Because I only sample a process with relatively high CPU usage, the
odds of swapping out the pages that I'm interested in should be really
small.

And I'm fine with getting a runtime warning when the memory page is
indeed swapped out, for example.

We are already able to fetch the current userspace backtraces in the
timer.profile context, for example. And it should be an excellent
addition if we can access more data like global variables in the
current user process.

> So, how to do what you want and be able to sample a user-space global
> variable at a timed interval? If the program has any timers itself, the
> easiest solution would be to probe the program's timer function.
>

Thank you for the suggestion but the values of my global variables
change *very* frequently and probing on every calls that may change
the variables is just a bit too expensive for me because I'm doing
online profiling in a production environment where reducing the
instrumentation cost means a lot.

Thanks!
-agentzh