[lttng-dev] problem starting trace on arm target
Hi, I am trying to use lttng-modules on an arm target, but when I try to start tracing I get some errors like PERROR: sendmsg: Bad file descriptor [in lttcomm_send_unix_sock() at sessiond-comm.c:310] PERROR: send consumer channel: Bad file descriptor [in send_kconsumer_session_streams() at main.c:636] please see pastebin (http://pastebin.com/ivnvQWa2) for complete logs I am using Linux 2.6.38 on Freescale imx6 platform. Lttng-modules 2.0.2 and lttng-tools 2.0.1 -- Fahad ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] problem starting trace on arm target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Fahad, This is error is a bit peculiar... Can you provide the full log of the session daemon like so. (term1) # lttng-sessiond -vvv (term2) the rest of the commands adding -vvv to lttng command line. Thanks! David On 09/05/12 08:20 AM, Fahad Usman wrote: Hi, I am trying to use lttng-modules on an arm target, but when I try to start tracing I get some errors like PERROR: sendmsg: Bad file descriptor [in lttcomm_send_unix_sock() at sessiond-comm.c:310] PERROR: send consumer channel: Bad file descriptor [in send_kconsumer_session_streams() at main.c:636] please see pastebin (http://pastebin.com/ivnvQWa2) for complete logs I am using Linux 2.6.38 on Freescale imx6 platform. Lttng-modules 2.0.2 and lttng-tools 2.0.1 -- Fahad ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJPqmxeAAoJEELoaioR9I02cTcH/3cXaG82+xpXQ2dnjtYeCgic FOOtPtdHEcfECVDk05MO0uc7fk5EJa1Am6cv4QXZJdO39qEpFOLe/iilRc0aXakr BKOcekqt4o804cru3sVTRiE87+TgsA9hpdWEBtaN1ykU2IIxRzmcahM56l/MFAwz +BT7x3Z1EGWUN7iOYMg26uLHHaXSnBgnZ0ZIbJ6rhJJ4NTOjJKZ69e/aTTkBTs5r YMCvd4orI4kY1DB8aP/HmsylIW7DRuS1a0gghQS/e9ELdJop2sld3gxjpat88CNN OAW+KJEWwhCVdTcOEyaGHR5SiEIH88U954GPkBZu3ifk3OkRIS6cpuDEt+DfMkE= =fZcW -END PGP SIGNATURE- ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Is it possible profiling android ice-cream ( kernel 3.0) with LTTng 2.0 ?
Hello im GJ and new of LTTng and Im trying to profiling kernel in android with LTTng 2.0. so i build up LTTng modules and got belows lttng-ring-buffer-client-discard.ko lttng-ring-buffer-client-mmap-discard.ko lttng-ring-buffer-client-mmap-overwrite.ko lttng/lttng-ring-buffer-client-overwrite.ko lttng/lttng-ring-buffer-metadata-client.ko lttng/lttng-ring-buffer-metadata-mmap-client.ko lttng/lttng-statedump.ko lttng/lttng-tracer.ko and i tried to insert modules to android kernel (actually im using galaxy nexus) but i only can insert lttng/lttng-statedump.ko not others I believed LTTng 2.0 is working on android (ice-crean cuz it has kernel 3.0) But now, im not sure about it :( So. I really want to ask you that Is it possible to use LTTng 2.0 on Android? and Did anyone success to do this? (not about previous LTT version) If so, please let me know. and i will really appreciate it if you shows kind of manuals or web pages. Thank you. ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [rp] [RFC] Readiness for URCU release with RCU lock-free hash table
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote: On Tue, May 08, 2012 at 02:48:27PM -0400, Mathieu Desnoyers wrote: * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote: On Mon, May 07, 2012 at 12:10:55PM -0400, Mathieu Desnoyers wrote: * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote: On Fri, May 04, 2012 at 12:53:12PM -0400, Mathieu Desnoyers wrote: [...] Just to make sure I understand -- the reason that the del functions say no memory barrier instead of acts like rcu_dereference() is that the del functions don't return anything. [...] @@ -391,6 +413,7 @@ int cds_lfht_del(struct cds_lfht *ht, struct cds_lfht_node *node); * function. * Call with rcu_read_lock held. * Threads calling this API need to be registered RCU read-side threads. + * This function does not issue any memory barrier. */ One more question about the del memory ordering semantic. Following commit commit db00ccc36e7fb04ce8044fb1be7964acd1de6ae0 Author: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Mon Dec 19 16:45:51 2011 -0500 rculfhash: Relax atomicity guarantees required by removal operation The atomicity guarantees for the removal operation do not need to be as strict as a cmpxchg. Use a uatomic_set followed by a xchg on a newly introduced REMOVAL_OWNER_FLAG to perform removal. Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com The del operation is performed in two steps: 1 - uatomic_or(), which sets the REMOVED flag (the actual tombstone) unconditionally into the node's next pointer. 2 - uatomic_xchg(), which atomically exchanges the old pointer with its current value (read) or'd with the REMOVAL_OWNER flag. The trick is that if the xchg returns a pointer with the REMOVAL_OWNER flag set, it means we are not the first thread to set this flag, so we should not free the node. However, if xchg returns a node without the REMOVAL_OWNER flag set, we are indeed the first to set it, so we should call free. Now regarding memory ordering semantics, should we consider the atomic action of del to apply when the or is called, or when the xchg is called ? Or should we simply document that the del effect on the node happens in two separate steps ? The way I see it, the actual effect of removal, as seen from RCU read traversal and lookup point of view, is observed as soon as the REMOVED tombstone is set, so I would think that the atomic publication of the removal is performed by the or. However, we ensure full memory barriers around xchg, but not usually around or. Therefore, the current implementation does not issue a memory barrier before the or, so we should either change our planned memory barrier documentation, or the implementation, to match. This would probably require creation of a cmm_smp_mb__before_uatomic_or(), so x86 does not end up issuing a useless memory barrer. My kneejerk reaction is that the or is really doing the deletion. Readers and other updaters care about the deletion, not about which CPU is going to do the free. Or did I misunderstand how this works? You got it right, this is how I see it too. However, in order to provide a full memory barrier before the or, we'd need to add a cmm_smp_mb() before the or (I don't think we want to presume that our or operation issues full memory barriers on all architectures). However, on x86, the lock; or does issue a full memory barrier. So I think we should introduce a macro that can translate into a memory barrier on architectures that need it, and to nothing on x86. Thoughts ? Makes sense to me! Allright, committed the following. I end up using cmm_smp_mb__before_uatomic_*. commit 7b783f818175cd92d98f78e761331f306ff406a5 Author: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Tue May 8 17:12:20 2012 -0400 rculfhash: document implied memory barriers We choose to provide full memory barriers before and after successful hash table update operations. Eventually, new API with weaker semantic can be added, but let's make the basic API as fool-proof as possible. Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com commit 196f4fab9bf26c48bc318ac2ff985469c4f62c7e Author: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Tue May 8 17:09:46 2012 -0400 rculfhash: Ensure future-proof memory barrier semantic consistency Use cmm_smp_mb__before_uatomic_or() prior to the uatomic_or() in _rcu_lfht_del() to ensure correct memory barrier semantic when we relax (in the future) the barrier implementation of some architectures.
Re: [lttng-dev] problem starting trace on arm target
Hi David, here are the logs on the two terminals, Term1: http://pastebin.com/dYGCrGcb Term2: http://pastebin.com/4XCn4Asv Please let me know if you want any other info from me. -- Fahad On Wed, May 9, 2012 at 6:08 PM, David Goulet dgou...@efficios.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Fahad, This is error is a bit peculiar... Can you provide the full log of the session daemon like so. (term1) # lttng-sessiond -vvv (term2) the rest of the commands adding -vvv to lttng command line. Thanks! David On 09/05/12 08:20 AM, Fahad Usman wrote: Hi, I am trying to use lttng-modules on an arm target, but when I try to start tracing I get some errors like PERROR: sendmsg: Bad file descriptor [in lttcomm_send_unix_sock() at sessiond-comm.c:310] PERROR: send consumer channel: Bad file descriptor [in send_kconsumer_session_streams() at main.c:636] please see pastebin (http://pastebin.com/ivnvQWa2) for complete logs I am using Linux 2.6.38 on Freescale imx6 platform. Lttng-modules 2.0.2 and lttng-tools 2.0.1 -- Fahad ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJPqmxeAAoJEELoaioR9I02cTcH/3cXaG82+xpXQ2dnjtYeCgic FOOtPtdHEcfECVDk05MO0uc7fk5EJa1Am6cv4QXZJdO39qEpFOLe/iilRc0aXakr BKOcekqt4o804cru3sVTRiE87+TgsA9hpdWEBtaN1ykU2IIxRzmcahM56l/MFAwz +BT7x3Z1EGWUN7iOYMg26uLHHaXSnBgnZ0ZIbJ6rhJJ4NTOjJKZ69e/aTTkBTs5r YMCvd4orI4kY1DB8aP/HmsylIW7DRuS1a0gghQS/e9ELdJop2sld3gxjpat88CNN OAW+KJEWwhCVdTcOEyaGHR5SiEIH88U954GPkBZu3ifk3OkRIS6cpuDEt+DfMkE= =fZcW -END PGP SIGNATURE- ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Is it possible profiling android ice-cream ( kernel 3.0) with LTTng 2.0 ?
On Wed, May 9, 2012 at 6:55 AM, GJ Chang gijae.ch...@gmail.com wrote: Hello im GJ and new of LTTng and Im trying to profiling kernel in android with LTTng 2.0. so i build up LTTng modules and got belows lttng-ring-buffer-client-discard.ko lttng-ring-buffer-client-mmap-discard.ko lttng-ring-buffer-client-mmap-overwrite.ko lttng/lttng-ring-buffer-client-overwrite.ko lttng/lttng-ring-buffer-metadata-client.ko lttng/lttng-ring-buffer-metadata-mmap-client.ko lttng/lttng-statedump.ko lttng/lttng-tracer.ko and i tried to insert modules to android kernel (actually im using galaxy nexus) but i only can insert lttng/lttng-statedump.ko not others I don't know about Android specifically, but I'm guessing your problem is that you're not inserting the kernel modules built in subdirectories. The canonical way to do that is using depmod (see the README for instructions), but if that doesn't work on Android, an ordering that works for installing all of the modules is: insmod probes/lttng-types.ko insmod probes/lttng-kretprobes.ko insmod probes/lttng-kprobes.ko insmod probes/lttng-ftrace.ko insmod lib/lttng-lib-ring-buffer.ko insmod lttng-statedump.ko insmod lttng-tracer.ko insmod probes/lttng-probe-timer.ko insmod probes/lttng-probe-statedump.ko insmod probes/lttng-probe-signal.ko insmod probes/lttng-probe-sched.ko insmod probes/lttng-probe-lttng.ko insmod probes/lttng-probe-kvm.ko insmod probes/lttng-probe-irq.ko insmod probes/lttng-probe-block.ko insmod lttng-ring-buffer-metadata-mmap-client.ko insmod lttng-ring-buffer-metadata-client.ko insmod lttng-ring-buffer-client-overwrite.ko insmod lttng-ring-buffer-client-mmap-overwrite.ko insmod lttng-ring-buffer-client-mmap-discard.ko insmod lttng-ring-buffer-client-discard.ko ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH] Create kernel events by writing to proc file
* Francis Giraldeau (francis.girald...@gmail.com) wrote: This feature allow to write events in the kernel trace stream by writing to the file /proc/lttng_user_event. The content is written unmodified to the trace as string type. The maximum string length saved per event is 256 bytes. The event type and the proc file are accessibles when the module lttng-user-event is loaded. This is a prototype implementation. The final implementation should avoid the temp copy of the string on the kernel stack. --- Makefile|1 + instrumentation/events/lttng-module/lttng.h | 19 +++ probes/Makefile |1 + probes/lttng-user-event.c | 159 +++ 4 files changed, 180 insertions(+), 0 deletions(-) create mode 100644 probes/lttng-user-event.c diff --git a/Makefile b/Makefile index dfa0792..6bd203d 100644 --- a/Makefile +++ b/Makefile @@ -24,6 +24,7 @@ lttng-tracer-objs := lttng-events.o lttng-abi.o \ obj-m += lttng-statedump.o lttng-statedump-objs := lttng-statedump-impl.o wrapper/irqdesc.o +lttng-user-event-objs := lttng-user-event.o ifneq ($(CONFIG_HAVE_SYSCALL_TRACEPOINTS),) lttng-tracer-objs += lttng-syscalls.o diff --git a/instrumentation/events/lttng-module/lttng.h b/instrumentation/events/lttng-module/lttng.h index 6f3d6d1..9da3c7e 100644 --- a/instrumentation/events/lttng-module/lttng.h +++ b/instrumentation/events/lttng-module/lttng.h @@ -6,6 +6,8 @@ #include linux/tracepoint.h +#define LTTNG_UEVENT_SIZE 256 + TRACE_EVENT(lttng_metadata, TP_PROTO(const char *str), @@ -28,6 +30,23 @@ TRACE_EVENT(lttng_metadata, TP_printk() ) +TRACE_EVENT(lttng_uevent, + + TP_PROTO(char *str), + + TP_ARGS(str), + + TP_STRUCT__entry( + __array_text( char, text, LTTNG_UEVENT_SIZE ) + ), + + TP_fast_assign( + tp_memcpy(text, str, LTTNG_UEVENT_SIZE) FYI, we have __string_from_user and tp_copy_string_from_user for that (you won't have to do the copy). + ), + + TP_printk(text=%s, __entry-text) +) + #endif /* _TRACE_LTTNG_H */ /* This part must be outside protection */ diff --git a/probes/Makefile b/probes/Makefile index 698a9c9..31ac769 100644 --- a/probes/Makefile +++ b/probes/Makefile @@ -14,6 +14,7 @@ obj-m += lttng-probe-sched.o obj-m += lttng-probe-irq.o obj-m += lttng-probe-signal.o obj-m += lttng-probe-timer.o +obj-m += lttng-user-event.o obj-m += lttng-probe-statedump.o diff --git a/probes/lttng-user-event.c b/probes/lttng-user-event.c new file mode 100644 index 000..d3b66e6 --- /dev/null +++ b/probes/lttng-user-event.c @@ -0,0 +1,159 @@ +/* + * lttng-user-event.c + * + * Copyright (C) 2006 Mathieu Desnoyers mathieu.desnoy...@efficios.com + * + * 2012-05-08 Ported to lttng 2 by Francis Giraldeau + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; only + * version 2.1 of the License. This file should be GPLv2, as below one function states that it is inspired from tracing_mark_write in the Linux kernel, which is licensed GPLv2. Or simply reimplement write_event: it will become _trivial_ with the proper zero-copy approach hinted at above. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* is there a prefered include order? */ nope +#include linux/module.h +#include linux/uaccess.h +#include linux/highmem.h +#include linux/sched.h +#include linux/gfp.h +#include linux/fs.h +#include linux/debugfs.h +#include linux/proc_fs.h +#include linux/slab.h +#include linux/mm.h +#include linux/string.h +#include linux/irqflags.h + +#include ../instrumentation/events/lttng-module/lttng.h + +DEFINE_TRACE(lttng_uevent); + +#define LTTNG_UEVENT_FILElttng_user_event + +struct proc_dir_entry *lttng_root; static. +static struct proc_dir_entry *write_file; + +/** + * write_event - write a userspace string into the trace system + * @file: file pointer + * @user_buf: user string + * @count: length to copy, including the final NULL + * @ppos: unused + * + * Copy a string into a trace event user_event. Pins pages in memory to avoid + * intermediate copy. + * + * On success, returns the number of bytes copied from the source. + * + * Inspired from tracing_mark_write implementation from Steven Rostedt
[lttng-dev] UST lttng enable-event output improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, i have a simple question which may lead to a small user experience improvement: lttng create tsession Session tsession created. Traces will be written in .../lttng-traces/tsession-20120510-015819 lttng enable-channel tchan -u -s tsession --subbuf-size=1024 UST channel tchan enabled for session tsession a message stating that buffer size is set to a value different than default would be nice lttng enable-channel tchan -u -s tsession --subbuf-size=1022 UST channel tchan enabled for session tsession What happens? Is it set to a value not power of 2? Is it set to the default value? (i guess the latter). The help says: - --subbuf-size SIZE Subbuffer size in bytes (default: 4096, kernel default: 262144) Needs to be a power of 2 for kernel and ust tracers Thanks, Ettore -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPqxEqAAoJEBroCbr/OjsafdAQAKKabbxxbEaX5KojAZe5Fqfz YqCweqj1k6EutxNl2MOEZNVTHpOMQVUZ6qtzvkrHndSA/yDUpWH1ivT70bIewjn5 SKQfu9OWhlhQR3W5CfHDHb4eE/38dzvkYc+AkS/VlH1gMD3NtWLeIF7BCPytmYKY XXaISNOZ5r9eL3Td5yOxNn8w3TsJfe54xVfuAY7CUD/nDovhKufFgyLF9QyrTLX1 xp5NZMNSrLDlbL4AWw6y96TKJacmzUp066RYD01cjnqNt6bIyxRGjePXZUsLtpfG +oHAct8PeKgYCtId6HJ6f5SbRfYrwX/aLQk3W1o8Ba9MvRb52LE2j29WpS1NJhcp LpQHZL6OOQFbXaTfqMI3pfhxi/TqT12wkxxPG3AYR5gxzovvOuAlknzlfjrzDnCs WK0PNA1++tPtgBSHl6cwcbNVW33KqIoEuG1wI7gVY/pJosvCXoSadra+TYatIhW7 rd53Z7G+P9jxU9Aq9nR/obATI2RSObSGAtLTHMTsYlTPB/e1TpC07CeHtgS0yUdP FpOuVkchOYt1FgO9CF7t7ndQGP0mLZscxWYKlvj2U15uQhHEzbk5YAuAtjbYoH/0 7bu1kDc3r+3Ll/6eynFJ3JzTd+6vQ+BQht8ulif+vUF1qkEB8XxPhwbXxKRWpf+S rG9FUiDO86ndDwHe5UjR =Q2pu -END PGP SIGNATURE- ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
