On 04 Dec (15:42:17), Thibault, Daniel wrote: > I'd appreciate a confirmation (or correction) of my understanding of > buffer multiplicity in user-space. Assume we have just the root session > manager running, and we've created a single session and enabled all > user-space events in the default channel channel0. > > In per-userID mode, if instrumented apps are running under several user > IDs, we will have one buffer (set of sub-buffers) per user ID, collecting > that userID's channel's events, and the consumer daemon simply round-robins > servicing the buffers to the matching sub-traces > (lttng-traces/session-name/ust/uid/1001/64-bit/channel0_0, > lttng-traces/session-name/ust/uid/1002/64-bit/channel0_0, etc.). > > Similarly, in per-processID mode, the buffer organization is the same > except that we have a buffer per process ID (regardless of each process's > owning userID), and the consumer daemon round-robins between a greater number > of buffers, dispatching the records to more sub-traces > (lttng-traces/session-name/ust/pid/app1-1001/channel0_0, > lttng-traces/session-name/ust/pid/app2-1001/channel0_0, > lttng-traces/session-name/ust/pid/app1-1002/channel0_0, etc.). > > In this latter case, don't we potentially run into a lot of overhead if a > multitude of short-lived processes occurs (i.e. going through the business of > creating a buffer every time)? Is the buffer creation triggered by the > process's registration with the session daemon, and does this slow the > process start up (i.e. does the registration call return immediately or does > it wait until the buffer is ready?)? If the registration call returns > immediately, what happens if the process emits an event before the buffer > creation is complete?
Starting with the first question (about overhead), yes with per PID it adds way more overhead since each process needs its own set of buffers. At registration, the session daemon ask the consumer to create buffers according with some properties asked by the application. Once done, the consumer sends back the reference to the session daemon and then sends that ref. to the application. From that point on, the application can start tracing and be assured that the first event will be collected. The UST registration blocks the application's main() until that process is completed meaning until the "registration done" message is received from the session daemon. Thus, the application *can't* emit an event during that time. Once it does, the sessiond/consumerd are already all set to handle tracing for that application. This is a "slow" process in the sense that with per-PID, if you have let say very short live applications and a huge number of them (in the thousands), that puts a lot of contention on the session daemon to create and cleanup apps concurrently thus possibly slowing down quite a bit. That's the tradeoff to accept some tracing guarantees. Of course there is always optimization to improve that process but we are not there yet. Cheers! David > > Daniel U. Thibault > Protection des systèmes et contremesures (PSC) | Systems Protection & > Countermeasures (SPC) > Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber > Security (MCCS) > R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D > Canada - Valcartier (DRDC Valcartier) > 2459 route de la Bravoure > Québec QC G3J 1X5 > CANADA > Vox : (418) 844-4000 x4245 > Fax : (418) 844-4538 > NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ> > Gouvernement du Canada | Government of Canada > <http://www.valcartier.drdc-rddc.gc.ca/> > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
signature.asc
Description: Digital signature
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
