[lttng-dev] Buffer multiplicity in user-space

[David Goulet]

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
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: Digital signature
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131204/fe904920/attachment.pgp>