De : Anand Neeli [mailto:[email protected]]
Envoyé : 7 avril 2014 10:37
> - It doesn't matter if the tracepoints are static or dynamically loaded with
> the app. Once there is a change in tracepoints the app should be reloaded
> (even though not compiled). Even though the tracepoints can be shared, but
> changing tracepoints we would need to restart all the app's which share the
> tracepoints.
(Just trying to make a statement on pros and cons here)
Not quite true. If the tracepoints are statically included in the app, then
the app must be recompiled and relinked whenever the tracepoints change.
Example:
static: static.o tp.o
@echo "~~~~~~Linking sample_$@:"
$(CC) -o sample_$@ $^ $(LDFLAGS) $(LIBDL) $(LIBUST)
@echo " Use './sample_$@' to run sample_$@"
static.o: sample.c tp.h
@echo "~~~~~~Compiling $@:"
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(TP_DEFINE) -c -o $@ $<
tp.o: tp.c tp.h
@echo "~~~~~~Compiling $@:"
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) -c -o $@ $<
Every time you change tp.h, you must recompile tp.o and static.o and relink
both into a new sample_static executable image. If you keep the tracepoint()
signatures unchanged, then you may get away with not recompiling static.o-but
you must still relink.
At the other extreme, if the app explicitly loads the tracepoint provider
using dlopen, then one could conceivably send a message to all apps to dlclose
the tracepoint provider shared object and dlopen a replacement one (if such an
API has been programmed in). The apps wouldn't need to stop running at all.
Of course this supposes the tracepoint() signatures do not change. (To avoid
confusing babeltrace, the traces must be collected using the buffers-pid
channel option and the changeover must not occur within the same one-second
time window)
> - * Does static or dynamic inclusion make difference(in terms of performance)
> if someone always want to run in tracing mode??
The difference will be slight: using a dynamic link, the linker must do a
little extra work when loading the tracepoint provider shared object along with
the application's binary image, just because it needs to find it elsewhere. So
you can expect app startup to be a little longer the first time. If the app is
using a tracepoint provider shared object which happens to be already used by
other running apps, the startup time actually becomes shorter because the
tracepoint provider shared object is already in memory.
Once the app is running, there should be no difference at all in performance.
> Now let me put some light on how someone would like to use lttngin huge
> codebases. (this is my personal opinion)
> - Normally tracepoints are made per component/daemon. And not shared across
> daemons/components.
> - Tracing should always be running. It should never be switched off. (unless
> the application is not mission critical)
> - I'm planning to always run memory(snapshot) tracing with some fixed size
> buffer, which can capture last n-events or n-bytes
> - Above memory tracing users can create another tracing session and dump
> traces to files if needed.(with their own filters and context in enable-event)
Sounds like a plan!
> Thanks again for spending your time on these queries.
> -Anand Neeli
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<--ESFSECEV-TY3011-------------------------------->
<http://www.travelgis.com/map.asp?addr=918V%20QSDJ<--ESFSECEV-TY3011-------------------------------->>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/<--ESFSECEV-TY3011--------------------->>
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
