[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1291073899-sup-7083@au1.ibm.com>
Date: Tue, 30 Nov 2010 10:45:40 +1100
From: Ian Munsie <imunsie@....ibm.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
linux-kernel <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 3/6] perf: Add timestamp to COMM and MMAP events
Hi Peter,
Excerpts from Peter Zijlstra's message of Mon Nov 29 22:54:50 +1100 2010:
> On Mon, 2010-11-29 at 17:06 +1100, Ian Munsie wrote:
> > This goes away if PERF_SAMPLE_CPU is added to the mix so that the
> > timestamps are offset from the first event of *their* CPU, otherwise
> > time-epoch can go negative, as it has done here.
>
> How does that happen, I though the power7 sched_clock() was fully
> synchronized and monotonic across all cores?
Oh the timestamps coming from the kernel are fine, I should have been
clearer in my email. This bug is purely restricted to the userspace code
that prints them out - in the perf_session__print_tstamp function. It
tries to print the timestamps out so that they start at 0 and if it
doesn't know what CPU the events came from it uses the very first event
it sees as epoch, but at the moment that is not necessarily going to be
the earliest event.
Thinking about it overnight, I realise that this should also go away if
we sort them before printing things out at all, which is exactly what
I'm proposing to do in my patches.
Cheers,
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists