Re: [ltt-dev] hybrid mode questions

Please apply the following fix on top of the previous one : I forgot to
add a new file into the git tree.


--- /dev/null
+++ b/include/ltt/ltt-facility-select-fs.h
@@ -0,0 +1,31 @@
+#ifndef _LTT_FACILITY_SELECT_FS_H_
+#define _LTT_FACILITY_SELECT_FS_H_
+
+#ifdef CONFIG_LTT
+#include <linux/ltt-facilities.h>
+#include <ltt/ltt-tracer.h>
+#include <ltt/ltt-facility-id-fs.h>
+
+/* ltt_get_index_from_facility
+ *
+ * Get channel index from facility and event id.
+ * 
+ * @fID : facility ID
+ * @eID : event number
+ *
+ * Get the channel index into which events must be written for the given
+ * facility and event number. We get this structure offset as soon as possible
+ * and remember it so we pass through this logic only once per trace call (not
+ * for every trace).
+ */
+static inline unsigned int ltt_get_index_from_facility_fs(u8 eID)
+{
+	switch (eID) {
+		case event_fs_exec:
+			return GET_CHANNEL_INDEX(processes);
+		default:
+			return GET_CHANNEL_INDEX(cpu);
+	}
+}
+#endif //CONFIG_LTT
+#endif //_LTT_FACILITY_SELECT_FS_H_



* Mathieu Desnoyers ([email protected]) wrote:
> Please try the following patch :
> 
> --- a/include/ltt/ltt-facility-select-default.h
> +++ b/include/ltt/ltt-facility-select-default.h
> @@ -30,7 +30,6 @@ static inline unsigned int ltt_get_index_from_facility(u8 eID)
>  #define ltt_get_index_from_facility_kernel_arch ltt_get_index_from_facility
>  #define ltt_get_index_from_facility_debug ltt_get_index_from_facility
>  #define ltt_get_index_from_facility_fs_data ltt_get_index_from_facility
> -#define ltt_get_index_from_facility_fs ltt_get_index_from_facility
>  #define ltt_get_index_from_facility_ipc ltt_get_index_from_facility
>  #define ltt_get_index_from_facility_locking ltt_get_index_from_facility
>  #define ltt_get_index_from_facility_memory ltt_get_index_from_facility
> diff --git a/include/ltt/ltt-tracer.h b/include/ltt/ltt-tracer.h
> diff --git a/ltt/probes/ltt-probe-fs.c b/ltt/probes/ltt-probe-fs.c
> index 5206308..e5a5030 100644
> --- a/ltt/probes/ltt-probe-fs.c
> +++ b/ltt/probes/ltt-probe-fs.c
> @@ -11,6 +11,7 @@
>  #include <linux/marker.h>
>  #include <linux/module.h>
>  #include <ltt/ltt-tracer.h>
> +#include <ltt/ltt-facility-select-fs.h>
>  #include <ltt/ltt-facility-select-default.h>
>  #include <ltt/ltt-facility-fs.h>
>  #include <ltt/ltt-facility-custom-fs_data.h>
> 
> * Mathieu Desnoyers ([email protected]) wrote:
> > * Jerry Hom ([email protected]) wrote:
> > > 
> > > Hi!  I'm revisiting the issue of hybrid mode.  I've been testing
> > > recently with kernel 2.6.18.3, LTTng 0.6.33, LTTV 0.8.72.  Since I'm
> > > mainly interested in process info (which currently seems to be in the
> > > medium rate channel) and don't need the high rate stuff, I tried
> > > running in hybrid mode and then stopping without dumping the flight
> > > recorder buffers.  The advantage with keeping only the medium and low
> > > rate channel is the much smaller log size.
> > > 
> > > However, the problem is that a bunch of process names and pids are
> > > missing.  The processes seem to be those which start after the initial
> > > kernel statedump, and they become generically named "swapper".  Also,
> > > their pids become '0'.  Can this be fixed easily?  Could you please
> > > point me in the direction to help fix this?
> > > 
> > 
> > Oh, I guess I have put the exec and compat_exec events in the high rate
> > channel right ? Should be in medium rate. Those events stamp the process
> > names.
> > 
> > I will dig into this soon. A patch would be welcome though :)
> > 
> > Mathieu
> > 
> > > On Thu, 14 Sep 2006, Mathieu Desnoyers wrote:
> > > 
> > > > * Jerry Hom ([email protected]) wrote:
> > > > > 
> > > > > I'm excited about the new hybrid mode, thanks!  It seems to address
> > > > > what I've been thinking.  Namely, I'm trying to gather a day long
> > > > > trace (eg, 8 hours), but the file sizes can reach 10GB+.  I have a
> > > > > question though about the high rate events in the flight recorder
> > > > > buffer.  Will that buffer always be dumped when the tracing is
> > > > > stopped?
> > > > > 
> > > > 
> > > > Only is the lttd daemon for reading (only) the flight recorder buffers is
> > > > spawned before the trace channel are destroyed. In the lttctl sequence of
> > > > operation I explained in the email earlier, yes, the flight recorder channels
> > > > are dumped and only then the trace channels are destroyed.
> > > > 
> > > > > Actually, for my purposes, I'm much more interested in the low rate
> > > > > events such as processes.  Perhaps a nice feature would be a toggle
> > > > > switch to turn on/off the high/medium/low rate events individually?
> > > > > 
> > > > 
> > > > Yes, and eventually, it would be great to multiplex them on the fly per event or
> > > > per facility. I guess it will eventually come as an extension to the filter
> > > > kernel module for dynamic event filtering (it's not implemented at all yet).
> > > > 
> > > > I'm glad it suits your needs!
> > > > 
> > > > Mathieu
> > > > 
> > > > 
> > > > > -- 
> > > > > Jerry Hom
> > > > > 
> > > > > _______________________________________________
> > > > > ltt-dev mailing list
> > > > > [email protected]
> > > > > http://www.listserv.shafik.org/listserv/listinfo/ltt-dev
> > > > > 
> > > > OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
> > > > Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
> > > > 
> > > 
> > > -- 
> > > Jerry Hom
> > > 
> > > _______________________________________________
> > > Ltt-dev mailing list
> > > [email protected]
> > > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> > > 
> > 
> > -- 
> > Mathieu Desnoyers
> > Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > _______________________________________________
> > Ltt-dev mailing list
> > [email protected]
> > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> [email protected]
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68