linux-kernel - Re: [PATCH] perf: POSIX CLOCK_PERF to report current time value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Dec 2013 13:07:50 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	Pawel Moll <pawel.moll@....com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Mike Galbraith <efault@....de>, Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	Sonny Rao <sonnyrao@...omium.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] perf: POSIX CLOCK_PERF to report current time value

* John Stultz <john.stultz@...aro.org> wrote:

> [...]
> 
> I'd much rather see perf export CLOCK_MONOTONIC_RAW timestamps, 
> since that clockid is well defined. [...]

So the problem with that clock is that it does the following for every 
timestamp:

        cycle_now = clock->read(clock);

... which is impossibly slow if something like the HPET is used, which 
is rather common - so this is a non-starter to timestamp perf events 
with. We use the scheduler clock as a reasonable compromise between 
scalability and clock globality.

I can see two solutions:

1)

One approach is what I described in my other reply a few minutes ago: 
track the flow of GTOD, timestamped with the fast perf timestamps, so 
that GTOD can be correlated to the perf clock, if user-space so 
wishes. The correlation is simple so this gets close to the ease of 
use of being able to timestamp GTOD directly.

(That would be useful for other purposes as well, such as 
instrumenting GTOD updates.)

2)

An alternate, rather interesting approach would be to change the 
scheduler clock offset to be influenced by the above events, so that 
it quasi-approximates GTOD and emits natural time of day timestamps.

This already happens partially in the sched-clock slow path, 
kernel/sched/clock.c's sched_clock_local(), it uses scd->tick_gtod 
timestamps to correlate to the monotonic clock. This could be changed 
over to use not get_ktime() but getnstimeofday(), to get true TOD 
timestamps.

The trickier bit is the x86 fast-path, in arch/x86/kernel/tsc.c's 
native_sched_clock(). That relies on __cycles_2_ns() to transform a 
CPU cycles timestamp into (boot time offset) nanoseconds. For that it 
uses the cyc2ns_offset percpu variable. That variable could be updated 
periodically so that it's TOD offset.

My (strong!) preference would be #2, for the simple reason that it 
would make perf timestamps instantly usable and tooling wouldn't have 
to do anything to get true timestamps. We could add a new 
PERF_SAMPLE_TIME_OF_DAY feature bit so that user-space can consciously 
request GTOD timestamps. This feature bit could even be arch 
influenced, so that architectures could convert their perf clocks at 
the pace they desire - which tooling can detect and handle safely.

Thoughts?

Thanks,

	Ingo
--
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/