<div dir="ltr"><div dir="ltr">We are experimenting LTTng for tracing multi-threaded program, it works very well for us. Thank you for having this great tool. But we have some concerns about the overhead and scalability of the tracing. Could you share some insight of the following questions?</div><div dir="ltr"><div>1. The session domain communicates with the user application via Unix domain socket, from LTTng document. is the communication frequent, such as each event requires communication, or the communication just happens at the beginning to configure user space tracing?</div><div>2. For the consumer domain, is the consumer domain has a thread per CPU/channel to write to disk or relay the traces, or it is a single threaded-process handling all the channels and ring buffers, which could become a bottleneck if we have large number of user threads all feeding traces?</div><div>3. In the one channel/ring buffer per CPU setting, if a user thread migrates from one CPU to another, are the traces generated by that user thread fed to the two channels/buffers for the two CPUs?</div><div>4. So far, the events for tracing can be enabled and disabled from command line, are you considering to have runtime options (APIs) to enable or disable certain events? Or this is the feature that already in or can be implemented in different way?</div><div>5. For context field, from the document, context fields cannot be removed from a channel once you add it. I would like to request a feature to allow removing context fields in the user program. </div><div><br></div><div>Thank you very much.</div><div>Yonghong</div><div><br></div><div><br></div></div></div>