Re: [PATCH] tools lib api: respect CROSS_COMPILE for the linker

BTW: s/env/command line/ is true as well, i.e. running: `make CROSS_COMPILE=cross-` On Tue, Mar 22, 2016 at 11:22 AM, David Sharp wrote: > So, note that without allow-override: > - The set default of "gcc" is not respected. > - Setting CC from the env does work. > - Sett

Re: [PATCH] tools lib api: respect CROSS_COMPILE for the linker

plained his reason for allow-override in the comment above it, >> > > > please make sure the new solution follows that >> > > >> > > Sure, and I'm no make guru, but what puzzles me is why isn't this >> > > required in: >> > > >> &

perf: TRACING_DATA header.size is invalid

We ran into an issue recently where a parser we have for perf.data could not handle TRACING_DATA events. It has a default behaviour of skipping event types it does not understand by using the header.size, since that seems to be how perf.data files are formatted. However, for TRACING_DATA events, h

Re: [PATCH] tracing: a few fields of struct trace_iterator are zeroed by mistake

ot;started" memory is lost after the first read > from tracing_read_pipe and a proper object will never be freed. > > The "started" is never dereferenced for trace_pipe, because trace_pipe > can't have the TRACE_FILE_ANNOTATE options (why?). > > Cc: Steven Rostedt

Re: [PATCH] tracing: Fix file mode of free_buffer

ree_buffer than >> the current file mode 0644. >> >> Signed-off-by: Wang YanQing > > Acked-by: Vaibhav Nagarnaik Acked-by: David Sharp > > Vaibhav Nagarnaik > > >> --- >> kernel/trace/trace.c | 2 +- >> 1 file changed, 1 insertion(+), 1 del

Re: [for-next][PATCH 0/8] tracing: Addition of multiple buffers

On Wed, Feb 27, 2013 at 9:22 AM, Steven Rostedt wrote: > With this patch set, a new directory is created in the debug/tracing > directory called "instances". Here you can mkdir/rmdir a new directory > that will contain some of the files in the debug/tracing directory. > Note, this is not totally f

[tip:perf/core] tracing: Format non-nanosec times from tsc clock without a decimal point.

Commit-ID: 8be0709f10e3dd5d7d07933ad61a9f18c4b93ca5 Gitweb: http://git.kernel.org/tip/8be0709f10e3dd5d7d07933ad61a9f18c4b93ca5 Author: David Sharp AuthorDate: Tue, 13 Nov 2012 12:18:22 -0800 Committer: Steven Rostedt CommitDate: Tue, 13 Nov 2012 15:48:40 -0500 tracing: Format non

[tip:perf/core] tracing,x86: Add a TSC trace_clock

Commit-ID: 8cbd9cc6254065c97c4bac42daa55ba1abe73a8e Gitweb: http://git.kernel.org/tip/8cbd9cc6254065c97c4bac42daa55ba1abe73a8e Author: David Sharp AuthorDate: Tue, 13 Nov 2012 12:18:21 -0800 Committer: Steven Rostedt CommitDate: Tue, 13 Nov 2012 15:48:27 -0500 tracing,x86: Add a TSC

Re: [PATCH 4/4] kernelshark: Full-height cursor and mark lines

On Wed, Nov 14, 2012 at 6:27 PM, Steven Rostedt wrote: > On Wed, 2012-11-14 at 17:51 -0800, David Sharp wrote: >> "width" and "height" were swapped, causing the vertical marker and cursor >> lines >> to be drawn with the wrong height. > > Is this t

[PATCH 4/4] kernelshark: Full-height cursor and mark lines

"width" and "height" were swapped, causing the vertical marker and cursor lines to be drawn with the wrong height. Signed-off-by: David Sharp --- trace-graph.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/trace-graph.c b/trace-graph.c in

Re: [PATCH 1/4] kernelshark: Fix bug with Plot CPU filtering

sorry for the dups... typoed Steve's domain. On Wed, Nov 14, 2012 at 5:51 PM, David Sharp wrote: > From: Venkatesh Pallipadi > > Plot CPU filtering in kernelshark has the following bug: > 1) Deselect CPU A from Plot CPU list > 2) Plot gets updated with no CPU A > 3) D

[PATCH 1/4] kernelshark: Fix bug with Plot CPU filtering

old_all_cpus != new_all_cpus before doing any update. This condition is true on 1, but false on 2. Removing that check fixes the problem. Tested: Above sequence now does expected filtering. Google-bug-id: 4258610 Signed-off-by: Venkatesh Pallipadi Signed-off-by: David Sharp --- trace-plot-cpu.c

[PATCH 3/4] kernel-shark: Don't check for system name for sched events

d the subsystem. Google-Bug-Id: 6333917 Signed-off-by: Vaibhav Nagarnaik Signed-off-by: David Sharp --- trace-graph.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/trace-graph.c b/trace-graph.c index 4d81219..6f72350 100644 --- a/trace-graph.c +++ b/trace-graph.c @@ -1

[PATCH 4/4] kernelshark: Full-height cursor and mark lines

"width" and "height" were swapped, causing the vertical marker and cursor lines to be drawn with the wrong height. Signed-off-by: David Sharp --- trace-graph.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/trace-graph.c b/trace-graph.c in

[PATCH 2/4] kernel-shark: Allow unsetting of all CPUs in filter

t CPUs and uncheck "All CPUs" button. All the CPUs should be unchecked at that point. Signed-off-by: Vaibhav Nagarnaik Signed-off-by: David Sharp --- trace-filter.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/trace-filter.c b/trace-filter.c ind

[PATCH 3/4] kernel-shark: Don't check for system name for sched events

d the subsystem. Google-Bug-Id: 6333917 Signed-off-by: Vaibhav Nagarnaik Signed-off-by: David Sharp --- trace-graph.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/trace-graph.c b/trace-graph.c index 4d81219..6f72350 100644 --- a/trace-graph.c +++ b/trace-graph.c @@ -1

[PATCH 1/4] kernelshark: Fix bug with Plot CPU filtering

old_all_cpus != new_all_cpus before doing any update. This condition is true on 1, but false on 2. Removing that check fixes the problem. Tested: Above sequence now does expected filtering. Google-bug-id: 4258610 Signed-off-by: Venkatesh Pallipadi Signed-off-by: David Sharp --- trace-plot-cpu.c

[PATCH 2/4] kernel-shark: Allow unsetting of all CPUs in filter

t CPUs and uncheck "All CPUs" button. All the CPUs should be unchecked at that point. Signed-off-by: Vaibhav Nagarnaik Signed-off-by: David Sharp --- trace-filter.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/trace-filter.c b/trace-filter.c ind

[tip:perf/core] tracing: Reset ring buffer when changing trace_clocks

Commit-ID: 60303ed3f4b9332b9aa9bc17c68bc174e7343e2d Gitweb: http://git.kernel.org/tip/60303ed3f4b9332b9aa9bc17c68bc174e7343e2d Author: David Sharp AuthorDate: Thu, 11 Oct 2012 16:27:52 -0700 Committer: Steven Rostedt CommitDate: Fri, 2 Nov 2012 10:21:47 -0400 tracing: Reset ring

[tip:perf/core] tracing: Trivial cleanup

Commit-ID: 01e3e710a9265fb7092efd67243d7b6dd6e2548a Gitweb: http://git.kernel.org/tip/01e3e710a9265fb7092efd67243d7b6dd6e2548a Author: David Sharp AuthorDate: Thu, 7 Jun 2012 16:46:24 -0700 Committer: Steven Rostedt CommitDate: Wed, 31 Oct 2012 16:45:33 -0400 tracing: Trivial cleanup

Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset

On Tue, Nov 13, 2012 at 6:00 PM, Steven Rostedt wrote: > On Wed, 2012-11-14 at 10:36 +0900, Yoshihiro YUNOMAE wrote: > >> To merge the data like previous pattern, we apply this patch set. Then, we >> can >> get TSC offset of the guest as follows: >> >> $ dmesg | grep kvm >> [ 57.717180] kvm: (2

[PATCH v9 2/3] tracing: Format non-nanosec times from tsc clock without a decimal point.

sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-off-by: David S

[PATCH v9 3/3] ftrace: Show raw time stamp on stats per cpu using counter or tsc mode for trace_clock

YUNOMAE Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Signed-off-by: David Sharp --- kernel/trace/trace.c | 23 +-- 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index d943e69..b69cc38 100644

[PATCH v9 1/3] tracing,x86: Add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups v7: Generic arch bits in Kbuild. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven

[PATCH v8 3/5] tracing: Format non-nanosec times from tsc clock without a decimal point.

sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-off-by: David S

[PATCH v8 2/5] tracing: Reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc

[PATCH v8 1/5] tracing,x86: Add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups v7: Generic arch bits in Kbuild. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven

[PATCH v7 1/5] tracing,x86: Add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups v7: Generic arch bits in Kbuild. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven

Re: [PATCH v6 1/6] tracing,x86: Add a TSC trace_clock

On Tue, Oct 16, 2012 at 5:53 AM, David Howells wrote: > David Sharp wrote: > >> > Please use the Kbuild infrastructure ("generic-y += ..." in >> > arch/*/include/asm/Kbuild) >> > instead of adding wrappers around the asm-generic version. >>

Re: [PATCH v6 1/6] tracing,x86: Add a TSC trace_clock

On Thu, Oct 11, 2012 at 10:05 PM, Geert Uytterhoeven wrote: > On Fri, Oct 12, 2012 at 1:27 AM, David Sharp wrote: >> +#include > > Please use the Kbuild infrastructure ("generic-y += ..." in > arch/*/include/asm/Kbuild) > instead of adding wrappers around

Re: [PATCH v6 1/6] tracing,x86: Add a TSC trace_clock

On Fri, Oct 12, 2012 at 4:41 AM, Steven Rostedt wrote: > On Fri, 2012-10-12 at 07:05 +0200, Geert Uytterhoeven wrote: >> On Fri, Oct 12, 2012 at 1:27 AM, David Sharp wrote: >> > +#include >> >> Please use the Kbuild infrastructure ("generic-y += ..." in

Re: [PATCH v6 6/6] tracing: Fix maybe-uninitialized warning in ftrace_function_set_regexp

On Thu, Oct 11, 2012 at 6:36 PM, Steven Rostedt wrote: > On Thu, 2012-10-11 at 16:27 -0700, David Sharp wrote: >> Compiler warning: >> >> kernel/trace/trace_events_filter.c: In function >> 'ftrace_function_set_filter_cb': >> kernel/trace/trace_event

Re: [PATCH 1/2] tracing: trivial cleanup

On Thu, Oct 11, 2012 at 6:56 PM, Steven Rostedt wrote: > Sorry, I know this is late, but it was pushed down in my todo list > (never off, but something I probably wouldn't have seen for a few more > months). > > On Thu, 2012-06-07 at 16:46 -0700, Vaibhav Nagarnaik wrote:

Re: [PATCH v5 1/3] tracing,x86: Add a TSC trace_clock

series? Thanks for noticing the stats issue. Added them to my series. > > Thanks, > > Yoshihiro YUNOMAE > > (2012/10/02 12:31), David Sharp wrote: >> In order to promote interoperability between userspace tracers and ftrace, >> add a trace_clock that reports raw T

[PATCH v6 3/6] tracing: Format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-

[PATCH v6 1/6] tracing,x86: Add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu

[PATCH v6 6/6] tracing: Fix maybe-uninitialized warning in ftrace_function_set_regexp

Compiler warning: kernel/trace/trace_events_filter.c: In function 'ftrace_function_set_filter_cb': kernel/trace/trace_events_filter.c:2074:8: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] Signed-off-by: David Sharp Cc: Steven Rosted

[PATCH v6 5/6] ftrace: Show raw time stamp on stats per cpu using counter or tsc mode for trace_clock

YUNOMAE Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Signed-off-by: David Sharp --- kernel/trace/trace.c | 23 +-- 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index cff3427..8bfa3b7 100644

[PATCH v6 2/6] tracing: Reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc

[PATCH v6 0/6] TSC trace_clock

Added Yoshihiro Yonomae's patches to change the per_cpu stats to show raw timestamps when the clock is not in nanoseconds. Also added a small patch to fix a warning. David Sharp (4): tracing,x86: Add a TSC trace_clock tracing: Reset ring buffer when changing trace_clocks tracing: F

[PATCH v6 4/6] ftrace: Change unsigned long type of ring_buffer_oldest_event_ts() to u64

Nagarnaik Signed-off-by: David Sharp --- include/linux/ring_buffer.h |2 +- kernel/trace/ring_buffer.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h index 6c8835f..c68a09a 100644 --- a/include/linux/ring_buffe

Re: [PATCH v5 3/3] tracing: Format non-nanosec times from tsc clock without a decimal point.

On Thu, Oct 11, 2012 at 1:43 PM, Steven Rostedt wrote: > On Mon, 2012-10-01 at 20:31 -0700, David Sharp wrote: > >> static int >> -lat_print_timestamp(struct trace_seq *s, u64 abs_usecs, >> - unsigned long rel_usecs) >> +lat_print_timestamp(st

[PATCH v5 3/3] tracing: Format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-

[PATCH v5 2/3] tracing: Reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc

[PATCH v5 1/3] tracing,x86: Add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu

Re: [PATCH v3 1/3] tracing,x86: add a TSC trace_clock

On Fri, Sep 28, 2012 at 8:15 PM, Steven Rostedt wrote: > On Thu, 2012-09-20 at 15:52 -0700, David Sharp wrote: > >> diff --git a/include/asm-generic/trace_clock.h >> b/include/asm-generic/trace_clock.h >> new file mode 100644 >> index 000..6726f1b >>

Re: [PATCH v4 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

On Wed, Sep 26, 2012 at 11:30 AM, Steven Rostedt wrote: > On Tue, 2012-09-25 at 15:29 -0700, David Sharp wrote: > >> static int >> -lat_print_timestamp(struct trace_seq *s, u64 abs_usecs, >> - unsigned long rel_usecs) >> +lat_print_timestamp(st

Re: [PATCH v4 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

On Tue, Sep 25, 2012 at 4:36 PM, Steven Rostedt wrote: > On Tue, 2012-09-25 at 15:29 -0700, David Sharp wrote: > > >> >> + ret = trace_seq_printf( >> >> + s, "[%08llx] %ld.%03ldms (+%ld.%03ldms): ", >> &

[PATCH v4 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-

Re: [PATCH v4 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

On Tue, Sep 25, 2012 at 2:42 PM, Steven Rostedt wrote: > Sorry, I should have been more picky before. I haven't totally tested > this yet. > > On Tue, 2012-09-25 at 13:49 -0700, David Sharp wrote: >> With the addition of the "tsc" clock, formatting timestamps to l

[PATCH v4 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. v4: Fix x86_32 build due to 64-bit division. Google-Bug-Id: 6980623 Signed-

Re: [PATCH v3 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

On Mon, Sep 24, 2012 at 8:27 PM, Steven Rostedt wrote: > On Thu, 2012-09-20 at 15:52 -0700, David Sharp wrote: >> With the addition of the "tsc" clock, formatting timestamps to look like >> fractional seconds is misleading. Mark clocks as either in nanoseconds or >>

Re: [PATCH v2 1/3] tracing,x86: add a TSC trace_clock

On Thu, Sep 20, 2012 at 1:55 AM, Ingo Molnar wrote: > Looks useful and good otherwise: > > Acked-by: Ingo Molnar Thanks! Updated with all your comments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo

[PATCH v3 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt

[PATCH v3 2/3] tracing: reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc

[PATCH v3 1/3] tracing,x86: add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu

Re: [PATCH v2 1/3] tracing,x86: add a TSC trace_clock

On Wed, Sep 12, 2012 at 6:23 PM, Steven Rostedt wrote: > This change will require an ack from one of the x86 maintainers. > > For reference to this patch, please see this thread: > > https://lkml.org/lkml/2012/9/11/572 > > On Wed, 2012-09-12 at 16:31 -0700, David Sharp

[PATCH v2 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... v2: Move arch-specific bits out of generic code. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt

[PATCH v2 2/3] tracing: reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc

[PATCH v2 1/3] tracing,x86: add a TSC trace_clock

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Ingo Molnar Cc: Thomas Gleixner Cc:

[PATCH v2 0/3] TSC trace_clock

Updated to move arch-specific bits out of generic code. I did this by adding a new file in asm-generic because I couldn't think of a better place to put it, but I'm open to suggestions. David Sharp (3): tracing,x86: add a TSC trace_clock tracing: reset ring buffer when changing tr

[PATCH v2 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

With the addition of the "tsc" clock, formatting timestamps to look like fractional seconds is misleading. Mark clocks as either in nanoseconds or not, and format non-nanosecond timestamps as decimal integers. Tested: $ cd /sys/kernel/debug/tracing/ $ cat trace_clock [local] global tsc $ echo sche

[PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. Google-Bug-Id: 6980623 Signed-off-by: David Sharp --- include/linux/trace_clock.h |3 +++ kernel/trace/trace.c|3 +++ kernel/trace/trace_clock.c | 16 +++

[PATCH v2 1/3] tracing,x86: add a TSC trace_clock

In order to promote interoperability between userspace tracers and ftrace, add a trace_clock that reports raw TSC values which will then be recorded in the ring buffer. Userspace tracers that also record TSCs are then on exactly the same time base as the kernel and events can be unambiguously inter

[PATCH v2 2/3] tracing: reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. --- kernel/trace/trace.c |8 1 files changed, 8 insertions(+),

Re: [PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change

On Tue, Sep 11, 2012 at 8:48 PM, Steven Rostedt wrote: > On Tue, 2012-09-11 at 19:41 -0700, David Sharp wrote: >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c >> index 5c38c81..dc1f1fa 100644 >> --- a/kernel/trace/trace.c >> +++ b/kernel/trace/trace.c &g

[PATCH 2/3] tracing: reset ring buffer when changing trace_clocks

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Signed-off-by: David Sharp --- kernel/trace/trace.

[PATCH 3/3] tracing: format non-nanosec times from tsc clock without a decimal point.

ext_prio=120 sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120 ... Google-Bug-Id: 6980623 Signed-off-by: David Sharp --- include/linux/ftrace_event.h |6 +++ kernel/trace/trace.c

[PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change

interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. Google-Bug-Id: 6980623 Signed-off-by: David Sharp --- include/linux/trace_clock.h |3 +++ kernel/trace/trace.c|3 +++ kernel/trace/trace_clock.c | 16 +++

[PATCH 0/3] TSC trace_clock

As discussed at Plumbers, here are my patches to add a TSC clock to ftrace. Also noticeable is that the formatting patch improves the output of the "counter" clock. David Sharp (3): tracing,x86: add a TSC trace_clock; reset buffer on clock change tracing: reset ring buffer whe