From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <52D57C33.2050908@siemens.com> Date: Tue, 14 Jan 2014 19:04:35 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <52D531E4.4040407@xenomai.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] filter ipipe tracing List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David , Gilles Chanteperdrix Cc: xenomai@xenomai.org On 2014-01-14 18:30, David wrote: > OK thanks, it helps to reduce by two factor (div 2) the number of trace per > milliseconds ; more importantly is CPU usage lowered from 100% down to 50%. > On a trace of 100000 points, i reached 250ms. 25% of these tracepoints are > __ipipe_syscall_root+xxx that does not mean anything to me, but all > syscalls, scheduling decisions and interrupts are visible. > > The resulting trace contains tracepoints on the current CPU that activates > the trace freeze. Is there a way to activate the simultaneous trace capture > on two+ cores ? > > I see trace_mark(...info...) in the Xenomai code. I don't think this info > is displayed in ipipe trace, am I wrong ? No, trace_mark are dead remainders of LTTng support. I'm slowly converting them to ftrace tracepoints that you can then retrieve and visualize with standard tools. It's an x86-64-only endeavor so far, artifacts can be found in [1] for Xenomai 2 (on maintenance now). For Xenomai 3, I didn't push anything yet. Jan [1] http://git.xenomai.org/xenomai-jki.git/log/?h=queues/ftrace -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux