On Sat, Feb 9, 2019 at 5:07 PM Milind Chabbi wrote:
>
> Can you give me more details about these terms: "g0", "systemstack", and
> "mcall"?
In Go, goroutines are multiplexed on to threads, so there are
typically many more goroutines than there are threads. Each thread
has an associated goroutin
I guess it depends on what you are logging/doing in response to the interesting
event, and where/when these occur, and how you are detecting them, as the
tracing of the context switch is very cheap.
> On Feb 9, 2019, at 8:10 PM, Milind Chabbi wrote:
>
> Robert,
>
> Tracing is not possible,
Robert,
Tracing is not possible, there will be trillions of instructions logged at
the instruction level tracing.
Let me elaborate a bit more.
The kind of tool I am thinking, intercepts every instruction being executed
on all OS threads in the go process.
The issue is that when an "interesting ev
Milind,
Understood. A few things to think about: 1) the tracing seems pretty efficient
in my tests, although if you don’t want a custom runtime, you’ll need to post
analyze on the file. 2) I think you are going to have a hard time doing what
you are trying to do because of the shared threads, y
Ian,
Can you give me more details about these terms: "g0", "systemstack", and
"mcall"?
Robert: taking the trace route is incorrect for me; I am profiling, tracing
is too expensive because of logging, furthermore, I don't want to recompile
the application or change the go runtime.
-Milind
On Sat
You also need to look at internal/trace to see how the runtime logs the trace
events related to the Go routines - that will show you where you need to
intercept.
> On Feb 9, 2019, at 4:29 PM, robert engels wrote:
>
> It is runtime/trace/trace.go
>
> It is what is reported in the trace facilit
On Sat, Feb 9, 2019 at 2:02 PM wrote:
>
> I am looking at fine-grained calling context collection for go lang programs
> (for all go routines) using binary instrumentation tools such as Intel Pin.
> In a traditional language such as C/C++ intercepting CALL/RET instructions
> (plus some special h
It is runtime/trace/trace.go
It is what is reported in the trace facility. It captures assigning Go routines
to OS thread (processor), and also switching Go routines on a logical processor
(OS thread).
You will still need to use OS level facilities to determine the context
switches of the OS t
It is slightly more advanced that that - since there are multiple OS threads
that the Go routines are multiplexed onto.
The easiest solution is to look at the ‘trace’ code as it records the context
switches.
> On Feb 9, 2019, at 3:34 PM, milis...@gmail.com wrote:
>
> I am looking at fine-grain
I am looking at fine-grained calling context collection for go lang
programs (for all go routines) using binary instrumentation tools such as
Intel Pin.
In a traditional language such as C/C++ intercepting CALL/RET instructions
(plus some special handling for exceptions setjmp/longjmp) suffices.
10 matches
Mail list logo
