[lttng-dev] subbuffers count and size

[Sebastien Boisvert]

Hi Vijay,


On 06/27/2016 06:12 AM, Vijay Anand wrote:
> Hi,
> 
> I have been trying to understand the impact of performance while logging user space program based on the subbuffer count and size.
> 

The sub-buffers count and size is well-documented here:

    http://lttng.org/docs/#doc-channel-subbuf-size-vs-subbuf-count



> I have a simple program logging 1 million traces 

Do you mean that you recorded 1 million UST events ?

Or do you mean that you traced your app 1 million times and you generated 1 million traces ?


> and I dont seem to see any appreciable performance between the below two configurations.
> 
> a. default 4 subbufers 128KB each
> b. 16 subbufers with 1024kB each.

When you are enabling your UST events (before starting the LTTng session), 
are you enabling your UST events in your custom channel (the one with configuration a. or configuration b.) ?


If not, it could explain the lack of difference in performance between your 2 configurations.


Example:

    lttng create

    lttng enable-channel -u --subbuf-size 4M channel7
    lttng enable-event -u -c channel7 gydle_om:Allocator_constructor_default

    lttng start

    run-your-app

    lttng stop
    lttng view > trace.txt



> 
> Moreover I have been looking at the lttng-ust code to understand the performance impacts from the implementation and unable to comprehend what is documented at 
> 
> http://lttng.org/docs/#doc-channel-subbuf-size-vs-subbuf-count
> 
> I see that channel_backend_init, _shm_object_table_alloc_shm seems to allocate one big shared memory chunk which again is subdivided into subbuffers with each subbuffer referenced using the subbufer index.
> 
> Further more lib_ring_buffer_write seems to find the subbuffer index and write "len" number of bytes into the subbuffer index.
> 
> Could anyone please enlighten me what is the overhead involved while switching from one subbufer to another as documented.
> 

The documentation indicates that the tracer's CPU overhead is caused by 2 things:

1) marking the current sub-buffer as consumable, and
2) switching to an empty sub-buffer.




> Regards,
> Vijay
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>