[ltt-dev] latest LTTng on 64bit RHEL

[Mathieu Desnoyers]

The userspace stack trace support seems to be in
arch/x86/kernel/stacktrace.c in mainline. If someone would like to use
that in a lttng probe so we can do userspace stack dump upon
system call/interrupt entry, that would be really nice.

Older lttng versions had the sequence type to do exactly that. A bit of
work would be needed to re-add this feature.

Mathieu

* Martin Kosina (martin_kosina at yahoo.com) wrote:
> So far, my main motivation has been similar to Joachim's (i.e. profiling a
> multithreaded server app with what we suspect are synchronization and i/o
> scalability issues), but eventually relating the timelines to network
> traffic between two traces would be extremely useful, yes.
> 
> As far as relating the instruction pointer to a stack trace in a user
> process, that does seem to have tremendous potential, as well. The only
> thing remotely similar I have found so far is the Intel thread profiler,
> which unfortunately seems to choke on any significant number of threads for
> me (well, the GUI does, anyway).
> 
> 
> 
> On Fri, Oct 16, 2009 at 5:26 AM, Mathieu Desnoyers <
> compudj at krystal.dyndns.org> wrote:
> 
> > BTW, there are improvements to LTTV on their way that will permit to
> > automatically synchronize traces collected from networked nodes from the
> > TCP traffic sequence numbers or added UDP synchronization.
> >
> > That might be something you'd like to look at. I'm CCing Benjamin
> > Poirier who is currently finishing his masters on this. He is in the
> > process of integrating the resulting algorithms to LTTV.
> >
> > Mathieu
> >
> >
> > * Martin Kosina (martin_kosina at yahoo.com) wrote:
> > > Yep, module loading problem between the two OS flavors, sorry for the
> > dumb
> > > question!
> > > Wonderful tool, btw, just starting to learn how to interpret all the
> > > data. We are looking into a more sophisticated / continuous profiling of
> > a
> > > network management system that collects data from hundreds of thousands
> > of
> > > devices (smart power grid infrastructure), looks like LTTng might work
> > very
> > > well.
> > >
> > > Best,
> > > Martin
> > >
> > >
> > > On Thu, Oct 15, 2009 at 6:53 PM, Mathieu Desnoyers <
> > > compudj at krystal.dyndns.org> wrote:
> > >
> > > > * Martin Kosina (martin_kosina at yahoo.com) wrote:
> > > > > Hi guys,
> > > > >
> > > > > Are there any known issues with running LTTng on em64t, specifically
> > on
> > > > > RHEL5 ? The traces run normally, but are basically empty, just a
> > single
> > > > > "unknown process" and just a bunch of "MODE_UNKNOWN" messages in the
> > > > Event
> > > > > Viewer and no timelines.
> > > > >
> > > > > Kernel is a 2.6.30.9 (built from git://
> > > > > git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-lttng.giton
> > > > the
> > > > > traced  host), latest ltt-control, and lttv from git. Traces built
> > from
> > > > the
> > > > > same sources on ia32 are working fine there. (The GUI is running on a
> > > > 32-bit
> > > > > box mounting the other machine's /tmp, FWIW).
> > > > >
> > > > > Thanks,
> > > > > Martin
> > > > >
> > > > >
> > > > > P.S. It all looks pretty normal when arming/running/stopping:
> > > > >
> > > > > [mkosina at metersim04 lttv]$ sudo /usr/local/bin/ltt-armall
> > > > > Connecting all markers
> > > > > Connecting /mnt/debugfs/ltt/markers/input/input_event
> > > > > Connecting /mnt/debugfs/ltt/markers/irq_state/idt_table
> > > > > Connecting /mnt/debugfs/ltt/markers/module_state/list_module
> > > > > Connecting /mnt/debugfs/ltt/markers/softirq_state/softirq_vec
> > > > > Connecting /mnt/debugfs/ltt/markers/swap_state/statedump_swap_files
> > > > > Connecting /mnt/debugfs/ltt/markers/syscall_state/sys_call_table
> > > > >
> > > >
> > > > Hrm, it looks like your LTTng probe modules are either not compiled or
> > > > not loaded.
> > > >
> > > > Can you give us a copy of your kernel .config and lsmod output ?
> > > >
> > > > Mathieu
> > > >
> > > > > [mkosina at metersim04 lttv]$ sudo /usr/local/bin/lttctl -C
> > --channel_root
> > > > > /mnt/debugfs/ltt -w /tmp/trace1 -o channel.all.overwrite=0 -n 1 trace
> > > > >
> > > > > Linux Trace Toolkit Trace Control 0.71-30092009
> > > > >
> > > > > Controlling trace : trace
> > > > >
> > > > > lttctl: Creating trace
> > > > > lttctl: Forking lttd
> > > > > Linux Trace Toolkit Trace Daemon 0.71-30092009
> > > > >
> > > > > Reading from debugfs directory : /mnt/debugfs/ltt/trace
> > > > > Writing to trace directory : /tmp/trace1
> > > > >
> > > > > [mkosina at metersim04 lttv]$ sudo /usr/local/bin/lttctl -D trace
> > > > > Linux Trace Toolkit Trace Control 0.71-30092009
> > > > >
> > > > > Controlling trace : trace
> > > > >
> > > > > lttctl: Pausing trace
> > > > > lttctl: Destroying trace
> > > >
> > > > > _______________________________________________
> > > > > ltt-dev mailing list
> > > > > ltt-dev at lists.casi.polymtl.ca
> > > > > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > > >
> > > >
> > > > --
> > > > Mathieu Desnoyers
> > > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE
> > 9A68
> > > >
> >
> > --
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> >

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68