* Adrian Hunter wrote:
> > I suspect you're talking about something else entirely;
> > your changelogs are inadequate for they tell ntohing of
> > your usecase and have me guessing. Don't do that.
>
> Sorry. I did mention Intel PT in patch 2, but I basically
> assumed the need to synchronize
On Thu, 2015-02-19 at 17:58 +, Pawel Moll wrote:
> and what Adrian did, explicitly
> defining possible timestamps at perf_event_attr level instead of
> relating them to to posix clock ids is the way to go. No strong opinion
> here.
One note here: I'd rather make it "processor trace clock", rat
On Thu, 2015-02-19 at 17:50 +, John Stultz wrote:
> On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter
> wrote:
> > On 19/02/2015 7:24 p.m., John Stultz wrote:
> >>
> >> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter
> >> wrote:
> >>>
> >>> Hi
> >>>
> >>> With the advent of switching perf_clock
On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter wrote:
> On 19/02/2015 7:24 p.m., John Stultz wrote:
>>
>> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter
>> wrote:
>>>
>>> Hi
>>>
>>> With the advent of switching perf_clock to CLOCK_MONOTONIC,
>>> it will not be possible to convert perf_clock direc
> > And NTP limits the slew rate to 500 PPM, so even if you would get a
Assuming you run NTP
>
> Assuming it is not broken.
It could also easily switch to HPET if the kernel decides the TSC has some
issues (which may be true or not).
The switching of the perf clock to MONOTONIC is a bad idea
On 19/02/2015 7:24 p.m., John Stultz wrote:
On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter wrote:
Hi
With the advent of switching perf_clock to CLOCK_MONOTONIC,
it will not be possible to convert perf_clock directly to/from
TSC. So add the ability to sample TSC instead.
Adrian Hunter (2):
On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter wrote:
> Hi
>
> With the advent of switching perf_clock to CLOCK_MONOTONIC,
> it will not be possible to convert perf_clock directly to/from
> TSC. So add the ability to sample TSC instead.
>
>
> Adrian Hunter (2):
> perf: Sample additional cloc
On 19/02/2015 5:05 p.m., Peter Zijlstra wrote:
On Thu, Feb 19, 2015 at 04:38:57PM +0200, Adrian Hunter wrote:
On 19/02/15 15:50, Peter Zijlstra wrote:
On Thu, Feb 19, 2015 at 02:11:08PM +0200, Adrian Hunter wrote:
Hi
With the advent of switching perf_clock to CLOCK_MONOTONIC,
it will not be p
On Thu, Feb 19, 2015 at 04:38:57PM +0200, Adrian Hunter wrote:
> On 19/02/15 15:50, Peter Zijlstra wrote:
> > On Thu, Feb 19, 2015 at 02:11:08PM +0200, Adrian Hunter wrote:
> >> Hi
> >>
> >> With the advent of switching perf_clock to CLOCK_MONOTONIC,
> >> it will not be possible to convert perf_clo
On 19/02/15 15:50, Peter Zijlstra wrote:
> On Thu, Feb 19, 2015 at 02:11:08PM +0200, Adrian Hunter wrote:
>> Hi
>>
>> With the advent of switching perf_clock to CLOCK_MONOTONIC,
>> it will not be possible to convert perf_clock directly to/from
>> TSC. So add the ability to sample TSC instead.
>
>
On Thu, Feb 19, 2015 at 02:11:08PM +0200, Adrian Hunter wrote:
> Hi
>
> With the advent of switching perf_clock to CLOCK_MONOTONIC,
> it will not be possible to convert perf_clock directly to/from
> TSC. So add the ability to sample TSC instead.
Well, you can, mostly. MONOTONIC is only affected b
Hi
With the advent of switching perf_clock to CLOCK_MONOTONIC,
it will not be possible to convert perf_clock directly to/from
TSC. So add the ability to sample TSC instead.
Adrian Hunter (2):
perf: Sample additional clock value
perf/x86: Provide TSC for PERF_SAMPLE_CLOCK_ARCH
arch/
12 matches
Mail list logo
