On Wed, Mar 14, 2018 at 12:55:20PM +, Jason Vas Dias wrote:
> > You could read the time using the group_fd's mmap() page. That actually
> > includes the TSC mult,shift,offset as used by perf clocks.
> >
>
> Yes, but as mentioned earlier, that presupposes I want to use the mmap()
> sample metho
On Wed, Mar 14, 2018 at 12:55:20PM +, Jason Vas Dias wrote:
> > If you want to correlate to CLOCK_MONOTONIC_RAW you have to read
> > CLOCK_MONOTONIC_RAW and not some random other clock value.
> >
>
> Exactly ! Hence the need for the patch so that users can get
> CLOCK_MONOTONIC_RAW values with
On Wed, Mar 14, 2018 at 12:55:20PM +, Jason Vas Dias wrote:
> > While CPU_CLOCK is TSC based, there is no guarantee it has any
> > correlation to CLOCK_MONOTONIC_RAW (even if that is also TSC based).
> >
> > (although, I think I might have fixed that recently and it might just
> > work, but it'
On Wed, Mar 14, 2018 at 12:55:20PM +, Jason Vas Dias wrote:
> > So you can avoid the whole ioctl(ENABLE), ioctl(DISABLE) nonsense and
> > just let them run and do:
> >
> > read(group_fd, &buf_pre, size);
> > /* your code section */
> > read(group_fd, &buf_post, size);
> >
> > /
Thanks for the helpful comments, Peter -
re:
On 14/03/2018, Peter Zijlstra wrote:
>
>> Yes, I am sampling perf counters,
>
> You're not in fact sampling, you're just reading the counters.
Correct, using Linux-ese terminology - but "sampling" in looser English.
>> Reading performance counters do
On Tue, Mar 13, 2018 at 11:45:45PM +, Jason Vas Dias wrote:
> On 12/03/2018, Peter Zijlstra wrote:
> > On Mon, Mar 12, 2018 at 07:01:20AM +, Jason Vas Dias wrote:
> >> Sometimes, particularly when correlating elapsed time to performance
> >> counter values,
> >
> > So what actual probl
On 12/03/2018, Peter Zijlstra wrote:
> On Mon, Mar 12, 2018 at 07:01:20AM +, Jason Vas Dias wrote:
>> Sometimes, particularly when correlating elapsed time to performance
>> counter values,
>
> So what actual problem are you tring to solve here? Perf can already
> give you sample time in v
Hi Jason,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
url:
https://github.com/0day-ci/linux/commits/Jason-Vas-Dias/x86-vdso-on-Intel-VDSO-should-handle-CLOCK_MONOTONIC_RAW/20180313-00
config: i386-tinyconfig (attached as .config)
compiler: gcc-
Currently the VDSO does not handle
clock_gettime( CLOCK_MONOTONIC_RAW, &ts )
on Intel / AMD - it calls
vdso_fallback_gettime()
for this clock, which issues a syscall, having an unacceptably high
latency (minimum measurable time or time between measurements)
of 300-700ns on 2 2.
On Mon, Mar 12, 2018 at 07:01:20AM +, Jason Vas Dias wrote:
> Sometimes, particularly when correlating elapsed time to performance
> counter values,
So what actual problem are you tring to solve here? Perf can already
give you sample time in various clocks, including MONOTONIC_RAW.
Currently the VDSO does not handle
clock_gettime( CLOCK_MONOTONIC_RAW, &ts )
on Intel / AMD - it calls
vdso_fallback_gettime()
for this clock, which issues a syscall, having an unacceptably high
latency (minimum measurable time or time between measurements)
of 300-700ns on 2 2.
Currently the VDSO does not handle
clock_gettime( CLOCK_MONOTONIC_RAW, &ts )
on Intel / AMD - it calls
vdso_fallback_gettime()
for this clock, which issues a syscall, having an unacceptably high
latency (minimum measurable time or time between measurements)
of 300-700ns on 2 2.
Currently the VDSO does not handle
clock_gettime( CLOCK_MONOTONIC_RAW, &ts )
on Intel / AMD - it calls
vdso_fallback_gettime()
for this clock, which issues a syscall, having an unacceptably high
latency (minimum measurable time or time between measurements)
of 300-700ns on 2 2.
13 matches
Mail list logo
