Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

[John Stultz <john.stultz@linaro.org>]

On 04/02/2013 12:54 AM, Peter Zijlstra wrote:
> On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
>> I'm still not sold on the CLOCK_PERF posix clock. The semantics are
>> still too hand-wavy and implementation specific.
> How about we define the semantics as: match whatever comes out of perf
> (and preferably ftrace by default) stuff?

That's not a sane interface. We've already been bitten by semantic 
changes in sched_clock affecting in-kernel users. How are we going to 
handle this with userland in the future? What happens when applications 
depend on "what comes out of perf" on one system and that ends up being 
different on another? "Oh, its just broken, the application shouldn't be 
using that."

I'm sort of amazed that folks are so careful and hesitant to add an 
ioctl to inject a timestamp fence into perf, but then so cavalier about 
adding a ill-defined clockid as a generic interface.


> Since that stuff is already exposed to userspace, doesn't it make sense
> to have a user accessible time source that generates the same time-line
> so that people can create logs that can be properly interleaved?

Its exposed to userspace as timestamps correlated with specific data, 
not timestamps for any purpose. We export kernel function addresses via 
WARN_ON messages to dmesg, it doesn't mean we might as well allow 
userland to jump and execute those addresses. ;)

I still think exposing the perf clock to userland is a bad idea, and 
would much rather the kernel provide timestamp data in the logs 
themselves to make the logs useful. But if we're going to have to do 
this via a clockid, I'm going to want it to be done via a dynamic posix 
clockid, so its clear its tightly tied with perf and not considered a 
generic interface (and I can clearly point folks having problems to the 
perf maintainers ;).


thanks
-john